Break the Monolith. But Only When You Actually Need To.

Start with a monolith. Microservices are the right answer when: you have distinct teams that deploy independently and need to avoid coordinating releases, you have services with very different scaling characteristics (your search endpoint needs 50x the resources of your auth endpoint), or you have clear domain boundaries that cause constant merge conflicts in a monolith. If none of those apply to you yet, a well-structured modular monolith is faster to build and cheaper to operate.

The signals that indicate it is time: your deployment pipeline takes 45+ minutes and everyone is blocked waiting for it, merge conflicts happen constantly because too many teams own overlapping code, a single slow background job affects your API response times, or you have one component that gets far more load than everything else. These are real operational pains — not theoretical architecture concerns.

Yes, almost always — in infrastructure, operational complexity, and engineering time. You need an API gateway, service discovery, distributed tracing, more CI/CD pipelines, and more observability tooling. The payoff is independent scalability and team autonomy. If those benefits do not outweigh the costs for your current scale, the monolith is the better business decision and we will tell you that directly.

Two-phase commit is generally not practical in microservices. The standard approach is the Saga pattern — either orchestration-based (a central coordinator) or choreography-based (services react to each other's events). We implement compensating transactions for rollback and use the outbox pattern to guarantee event delivery even when the publishing service crashes mid-transaction. The right approach depends on your consistency requirements.

REST (or gRPC) is appropriate for synchronous request-response where you need an immediate answer — authentication checks, payment processing, fetching a resource. Event-driven (Kafka/RabbitMQ) is appropriate for async workflows where eventual consistency is acceptable — order processing, notification sending, reporting data pipelines. Most real systems use both. Event sourcing (where the event log is the source of truth) is a separate pattern with significant complexity — we recommend it only for specific audit-heavy domains.

A service mesh (Istio, Linkerd) handles mTLS between services, circuit breaking, retries, and distributed tracing at the infrastructure level — without application code changes. You probably do not need it until you have 10+ services and your team finds it difficult to reason about inter-service communication security and reliability. The operational overhead of Istio especially is significant. We often recommend handling these concerns in the application layer (Resilience4j for Java, retry/timeout middleware for Node) for teams under that threshold.