← Back to experience
Mid-size SaaS company Senior Backend Developer

API Platform Migration to Microservices

Led the decomposition of a monolithic REST API into independently deployable microservices, reducing average response time by 40% and enabling teams to ship independently.

  • Python
  • FastAPI
  • PostgreSQL
  • Redis
  • Docker
  • Kubernetes
  • nginx

The Problem

The platform had grown from a startup MVP into a monolithic API serving
several hundred thousand active users. Every feature team worked inside the
same codebase, and a single slow database query could degrade unrelated
endpoints. Deployments required coordinating across four engineering teams
and carried enough risk that the release cadence had slipped to once a week.

Constraints

  • Zero-downtime migration required — the API served 24/7 production traffic
  • Four engineers, six-month timeline
  • Existing clients (mobile apps, third-party integrations) could not change
    their API calls
  • No dedicated infrastructure team; we owned our own deployments

My Approach

I proposed and led the adoption of the strangler fig pattern: route
all traffic through a thin API gateway, then migrate one domain at a time
by extracting it to its own service and redirecting gateway rules. The
monolith shrank gradually while new services went live in parallel.

Key decisions I drove:

  • Gateway-first: deployed an nginx-based gateway before touching any
    service logic, giving us routing control from day one
  • Contract testing: introduced consumer-driven contract tests so we
    could verify that the extracted services respected every client expectation
    before switching traffic
  • Database-per-service with a shared read replica during transition:
    avoided a big-bang data migration while still enabling the monolith and
    new services to read from the same data during the cutover window

Results

  • Average API response time dropped by 40% after the first three services
    were extracted (the highest-traffic, slowest endpoints)
  • Deployment frequency increased from once weekly to multiple times per day
    per team
  • Zero customer-facing incidents during the migration
  • The monolith was fully retired within eight months (two months ahead of
    schedule)

What I’d Do Differently

I underestimated how much time shared-database coordination would consume.
Next time I would negotiate a longer data-isolation phase upfront rather
than treating the shared replica as a low-risk temporary measure — it
created subtle coupling that took extra weeks to unwind.

I would also have pushed harder for feature-flag infrastructure earlier.
We improvised per-service feature flags from environment variables, which
worked but was messy. A proper flag service would have made the gradual
traffic-shift rollouts cleaner.


This demonstrates

  • System design
  • Technical leadership
  • Migration strategy
  • Performance optimisation
  • Contract testing