Microservices Migration: When and How to Split the Monolith

Do You Actually Need Microservices?

Most companies that migrate to microservices do it too early. A monolith that works is better than microservices that are half-built. Before migrating, ask: what specific problem will microservices solve that you cannot fix in your current architecture?

Valid reasons to migrate: different parts of your system need to scale independently, multiple teams are blocked by merge conflicts and deployment dependencies, or you need different technology stacks for different components. Invalid reasons: "everyone is doing it," "it will make us more agile," or "our architecture is getting complex." Microservices add operational complexity. Make sure the benefits outweigh the costs.

The Strangler Fig Pattern

Do not rewrite your monolith from scratch. That approach has a failure rate above 70% in our experience. Use the strangler fig pattern instead: gradually replace parts of the monolith with new services, one piece at a time.

The process:

1. Identify the first candidate. Pick a module that is relatively independent, changes frequently, and has clear boundaries. Payment processing, notification systems, or user authentication are common first candidates.
2. Build the new service. Implement the same functionality as a standalone service with its own database and API.
3. Route traffic. Put a proxy in front of both the monolith and the new service. Route requests for the migrated functionality to the new service while everything else goes to the monolith.
4. Verify and cut over. Run both in parallel for 2-4 weeks. Compare outputs. When they match, remove the old code from the monolith.
5. Repeat. Pick the next candidate and do it again.

Finding Service Boundaries

The hardest part of microservices is deciding where to draw the boundaries. Do it wrong and you end up with services that are too chatty (making dozens of API calls to each other for a single user action) or too large (defeating the purpose of splitting).

Use domain-driven design (DDD) bounded contexts as a starting point. A bounded context is a part of your system where a particular domain model applies. "Users" might mean different things in your billing system vs your product: billing cares about payment methods and subscription status, while the product cares about preferences and activity.

A practical test: if two pieces of functionality need to share the same database table, they probably belong in the same service. If they can operate with eventual consistency between them (updates can take a few seconds to propagate), they can be separate services.

Operational Readiness

Before migrating, make sure your team can operate microservices:

• Observability. You need centralized logging (ELK stack or similar), distributed tracing (Jaeger, Zipkin), and monitoring (Prometheus/Grafana or Datadog). Without these, debugging production issues across services is nearly impossible.
• CI/CD per service. Each service needs its own deployment pipeline. If deploying one service requires deploying others, your boundaries are wrong.
• Service discovery. Services need to find each other. Kubernetes handles this natively. If you are not on Kubernetes, you need a service registry or DNS-based discovery.
• Team structure. Each service should have a clear owner. If one team owns 15 services, that is too many. Two to three services per team is a good ratio.

If you do not have these capabilities today, build them before migrating. Microservices without observability is flying blind in a thunderstorm.

Preguntas Frecuentes