After this lesson, you will be able to: Compare microservices vs monolith honestly, identify when each fits, and avoid the cargo-cult adoption pattern.
Microservices are the most over-prescribed architecture pattern in modern engineering. This lesson covers the real tradeoffs, when microservices actually pay off, and the modular monolith middle ground.
A system where each service: owns its data (its own database, never shared); deploys independently (its own pipeline, own version); communicates via well-defined APIs (HTTP, gRPC, events); is owned by one team. If two 'services' share a database or deploy together, they're a monolith with extra steps.
Operational overhead: every service needs its own deploy, monitoring, logging, on-call, runbook. Network failures: in-process calls always succeed; network calls fail randomly. Every service-to-service call needs timeouts, retries, circuit breakers. Data consistency: no more cross-service transactions. Sagas, eventual consistency, idempotency keys become a daily concern. Developer experience: 'run the project locally' becomes 'spin up 8 services + their databases'. Distributed tracing: debugging a request that spans 6 services needs tracing infra you didn't need before.
Different scaling profiles: one component is CPU-bound, one is I/O-bound; running them as separate services lets each scale on its own metric. Different deploy cadences: the billing service ships quarterly with audits; the marketing site ships daily. Separating them is a process win, not a code win. Different teams owning different parts: at 100+ engineers, one monolith causes constant merge conflicts and team coordination overhead. Different tech stacks: ML pipeline in Python; main app in TypeScript. Separation is the only sane way. If NONE of these apply, microservices cost more than they save.
Build/test time exceeds 30 min and people stop running them locally. Two teams have started 'sharding' the codebase by directory and stepping on each other's toes. Different parts of the app need to scale on wildly different schedules and you can't tune them separately. Release coordination across teams is the dominant cost of shipping. If you have NONE of these problems, you don't have a microservices problem; you have a discipline problem inside your monolith.
Adopting microservices in year 1 of a startup. The product hasn't found fit; the cost outweighs every benefit. Splitting on weak boundaries (auth service, user service, profile service all read/write the same `users` table). That's a monolith with extra latency. Treating service boundaries as forever-decisions. Boundaries should be reversible; treat them as hypotheses you can refute. Skipping distributed tracing. You'll be blind the first time a request fails across 6 services. OpenTelemetry from day one. Believing every FAANG architecture applies to your 20-person startup. Most don't.
Pick the most senior recommendation.
Sign in and purchase access to unlock this lesson.