Skip to main content

Microservices Architecture

A microservices architecture splits a system into many small, independently deployable services, each owning a specific piece of functionality and, typically, its own data. It's the opposite structural choice from a monolith — one large application, one codebase, one deployment unit — and the entire Distributed Systems and Microservices module was, in effect, building up the vocabulary this lesson needed to describe precisely.

What "independent" actually buys​

The value of microservices isn't "smaller code" — plenty of monoliths are well-organized internally. The value is that each service can be deployed, scaled, and owned independently: a team can ship a change to the payments service without coordinating a release with the team owning search, and a service under heavy load can be scaled up on its own without scaling everything else along with it. This is the same horizontal scaling idea applied at the level of whole services instead of instances of one service.

System Design Lab

Independence isn't free — it's a trade for coordination cost​

Everything that made a monolith simple becomes explicit, distributed infrastructure once services are split apart, and naming each piece is what makes this lesson a capstone for the whole module rather than a new topic:

  • Finding each other — a function call inside one process becomes a network call to a service whose address isn't fixed, which is exactly the problem Service Discovery solves.
  • Surviving a dependency failing — a call to another service can fail in ways an in-process function call never does, which is why Circuit Breakers and sensible retry/timeout policies become mandatory rather than optional.
  • Routing and cross-cutting concerns — auth, rate limiting, and routing to the right service all need a shared answer, which is the role an API Gateway plays.
  • Debugging across services — a single request's path through many services needs to be reconstructed after the fact, which is exactly what Distributed Tracing is for, precisely because a monolith's single stack trace no longer exists.
  • Data consistency across services — each service typically owns its own database, so a transaction that used to be one ACID operation inside one database is now a multi-service operation with no single transaction to wrap it, which is why Event-Driven Architecture patterns (publishing events other services react to) become the standard way to keep services eventually in sync instead.

None of this infrastructure exists in a monolith, because a monolith doesn't need it — one process, one shared memory space, one database, no network calls between its own internal pieces at all.

When microservices are worth the coordination tax​

The tradeoff is real and worth naming honestly: microservices trade simplicity for independent scalability and deployability. That trade pays off when an organization is large enough that independent teams genuinely need to ship on separate schedules, or when different parts of a system have genuinely different scaling needs (a search service under 100x the load of an admin dashboard). It pays off poorly for a small team or an early-stage product, where the operational overhead of running many services outweighs any benefit — which is why "start with a monolith, split out services once you actually feel the pain of not having them" is common, well-regarded advice, not a cop-out.

Why this matters in an interview​

Proposing microservices should come with the specific reason this system needs independent scaling or independent deployment — not as a default "modern" choice. Just as importantly, naming the infrastructure that decomposition requires (discovery, circuit breakers, tracing, an event-driven path for cross-service consistency) shows the tradeoff is understood as a real cost, not a free architectural upgrade.

Microservices vs. a monolith: pros and cons​

Pros

  • Each service scales and deploys independently, matching capacity to actual demand
  • Teams can own and ship a service without coordinating releases with every other team
  • A failure in one service doesn't necessarily take down unrelated functionality

Cons

  • Requires solving service discovery, resilience, and tracing that a monolith gets for free
  • Cross-service data consistency replaces simple in-process transactions with harder distributed patterns
  • Meaningfully more operational complexity — many deployables instead of one

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.