system-design · intermediate

Microservices Architecture — Independently Deployable Pieces

Start here

Microservices architecture structures a product as many small(ish) services that:

• Are independently deployable
• Own their data (ideally)
• Communicate over the network (HTTP, gRPC, events)
• Align with team boundaries (Conway’s law awareness)

What you will learn

1. Define microservices vs modular monolith.
2. See benefits: autonomy, selective scale, isolation.
3. See costs: latency, consistency, ops, debugging.
4. Work a complete commerce split example.
5. Apply rules of thumb for service boundaries.
6. Avoid distributed monolith anti-patterns.

What you should know first

Words you need before we begin

Simple story: food court vs one mega-kitchen

A food court (microservices) has specialized stalls with their own inventory. A single mega-kitchen (monolith) shares one freezer and schedule. Stalls scale sushi independently, but getting a full meal may mean multiple queues and more walking (network hops).

The problem microservices try to solve

• Large teams blocking on one release train
• Scaling the whole monolith for one hot endpoint
• Fault isolation (one module’s memory leak killing everything)
• Polyglot needs (rare but real)

Step-by-step: adopting thoughtfully

Step 1 — Start with modular monolith boundaries

Packages/modules with clear APIs even inside one deployable.

Step 2 — Identify split candidates

Different scale, different compliance, different team ownership, frequent independent change.

Step 3 — Define contracts first

Versioned APIs/events; consumer-driven tests.

Step 4 — Separate data

No shared write DB across services. Integrate via APIs/events.

Step 5 — Provide platform basics

Discovery, gateway, observability, CI/CD, on-call.

Step 6 — Choose sync vs async per use case

User-facing authorize vs async email.

Step 7 — Measure the tax

Track deploy frequency gains vs incident complexity.

Visual mental model

flowchart LR
  GW[API gateway] --> Cat[Catalog service]
  GW --> Cart[Cart service]
  GW --> Ord[Order service]
  Ord --> Pay[Payment service]
  Ord -->|events| Mail[Email service]
  Cat --> CatDB[(Cat DB)]
  Ord --> OrdDB[(Ord DB)]

Learning question: Why is a shared company_db for all services a red flag?

Caption: It couples deploys and schemas—distributed monolith territory.

Complete worked example: commerce split

Starting situation

Monolith slows releases; catalog team blocked by checkout freezes.

Decisions

Failure design

Payments timeout → fail order create carefully; never double charge (idempotency keys). Email down → order still succeeds.

Outcome

Catalog deploys thrice daily. Cost: need gateway, tracing, contract tests, more dashboards.

How it works in production

• Containers + orchestrators
• Central logging/metrics/tracing
• SLOs per service
• Platform teams enable product teams

Failure modes

Trade-offs

Compare with related concepts

Common misunderstandings

1. “Microservice = small file count.” Size is about independence, not LOC pride.
2. “Network is reliable.” Design for partial failure.
3. “One DB is fine if schemas differ.” Still coupling.
4. “We will find boundaries later.” Wrong splits are expensive—iterate carefully.
5. “Kubernetes means we have microservices.” Platform ≠ architecture.

Check your understanding

1. Name three benefits and three costs.
2. What is a distributed monolith?
3. Why own data per service?
4. When keep a monolith?
5. How do events help side effects?

Practice

1. Propose three services for a ride-sharing app and their data.
2. Identify a bad split (e.g., splitting by technical layer only).
3. Design failure behavior when payments is down.
4. List minimum platform capabilities before splitting.
5. Critique a diagram with 40 services for a 6-person team.

Deeper production notes

Team topology

If you cannot staff on-call for a service, do not create it. Ownership is the scarce resource.

Contract testing

Without consumer-driven tests, independent deploys become production roulette.

Strangler pattern

Extract gradually from a monolith rather than big-bang rewrites.

Additional teaching scenarios

Scenario A — peak load day

Scenario B — mixed versions

Scenario C — five-sentence teach-back

Scenario D — metrics and alerts

Scenario E — non-goals

Scenario F — ownership

Revision summary

• Microservices = independent deploy + ownership + network.
• Benefits trade against distributed complexity.
• Prefer modular monolith until pain is real.
• Split data and invest in platform & contracts.

Glossary

Abbreviations and terminology

• LOC — Lines of code
• ESB — Enterprise service bus
• SLO — Service level objective
• CI/CD — Continuous integration / delivery

What to learn next

1. Split a monolith safely
2. Service discovery
3. Event-driven architecture
4. Outbox and sagas

Extra teaching notes for first-time builders

Write the single bottleneck you are protecting before picking tools. Name the signal that tells you the design is working for users, not only that internal counters move. When reviewing a change related to this lesson, ask what happens when the component is slow for ten minutes, down entirely, or running twice. Prefer small explicit failure modes that operators can understand at 3 a.m.

Document ownership for dashboards, code, and pages. Undocumented mechanisms become folklore and then outages. Prefer designs that tolerate mixed versions for at least one deploy window so rollouts do not require perfect global simultaneity.

Napkin math helps: estimate peak rate, multiply by payload size, and ask whether the design still holds when a dependency is at half capacity. If the answer depends on luck, add bounds, backpressure, or shedding before production traffic arrives.

Extra teaching notes for first-time builders

Write the single bottleneck you are protecting before picking tools. Name the signal that tells you the design is working for users, not only that internal counters move. When reviewing a change related to this lesson, ask what happens when the component is slow for ten minutes, down entirely, or running twice. Prefer small explicit failure modes that operators can understand at 3 a.m.

Document ownership for dashboards, code, and pages. Undocumented mechanisms become folklore and then outages. Prefer designs that tolerate mixed versions for at least one deploy window so rollouts do not require perfect global simultaneity.

Napkin math helps: estimate peak rate, multiply by payload size, and ask whether the design still holds when a dependency is at half capacity. If the answer depends on luck, add bounds, backpressure, or shedding before production traffic arrives.

Extra teaching notes for first-time builders

Write the single bottleneck you are protecting before picking tools. Name the signal that tells you the design is working for users, not only that internal counters move. When reviewing a change related to this lesson, ask what happens when the component is slow for ten minutes, down entirely, or running twice. Prefer small explicit failure modes that operators can understand at 3 a.m.

Document ownership for dashboards, code, and pages. Undocumented mechanisms become folklore and then outages. Prefer designs that tolerate mixed versions for at least one deploy window so rollouts do not require perfect global simultaneity.

Napkin math helps: estimate peak rate, multiply by payload size, and ask whether the design still holds when a dependency is at half capacity. If the answer depends on luck, add bounds, backpressure, or shedding before production traffic arrives.

Extra teaching notes for first-time builders

Write the single bottleneck you are protecting before picking tools. Name the signal that tells you the design is working for users, not only that internal counters move. When reviewing a change related to this lesson, ask what happens when the component is slow for ten minutes, down entirely, or running twice. Prefer small explicit failure modes that operators can understand at 3 a.m.

Document ownership for dashboards, code, and pages. Undocumented mechanisms become folklore and then outages. Prefer designs that tolerate mixed versions for at least one deploy window so rollouts do not require perfect global simultaneity.

Napkin math helps: estimate peak rate, multiply by payload size, and ask whether the design still holds when a dependency is at half capacity. If the answer depends on luck, add bounds, backpressure, or shedding before production traffic arrives.

FAQ from first-time learners

Q: How small should a service be?
A: Small enough for one team to own fully; large enough to avoid chatty networks.

Q: Is a modular monolith “legacy”?
A: No—it is often the correct default.

Q: Do microservices require Kubernetes?
A: No, but you need some mature deploy and discovery story.

Track: Software Design and Architecture

Previous: Fan-out on Write vs Fan-out on Read

Next: Notification System Design — Reference Architecture

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab