Embrace the Future of Software Architecture

Embrace the Future of Software Architecture: Microservices Patterns

"Microservices" is not a goal — it is a trade. You give up the simplicity of one deployable and one database, and in return you buy the ability for many small teams to build, deploy, and scale their slices of a product independently. The patterns in this lesson exist because the moment you cut a monolith into services, a set of hard problems appears that the monolith solved for free: a single call now crosses the network, a single transaction now spans machines, and a single query now touches data you no longer own. The patterns are the disciplined answers to those problems.

1. Plain-language intuition

Picture a monolith as one big office where everyone shares the same filing cabinet. Calling a function is walking across the room; a database transaction is one person locking the cabinet for a second. It is fast and correct, but everyone deploys together — one team's bad line of code takes the whole building down, and you can only scale by cloning the entire building.

Microservices split that office into many small buildings, each owning its own filing cabinet (database-per-service). Amazon can now scale Checkout to 200 instances while Reviews runs on 3. The Payments team ships 40 times a day without asking anyone. But now "walking across the room" is a network hop that can time out, and "locking the cabinet" is impossible because there is no shared cabinet. The patterns — API Gateway, Saga, CQRS, Circuit Breaker, Sidecar — are the plumbing that makes independent buildings behave like one coherent system.

2. How it works, precisely

A production microservices system is a stack of named patterns, each solving one failure the split created:

• Decomposition: split by business capability or bounded context (a DDD term), not by technical layer. Orders, Inventory, Payments — never Controllers, Services, DAOs. Each owns its data exclusively.
• API Gateway / BFF: a single ingress that fans out to internal services, handling auth, rate-limiting, TLS termination, and response aggregation so clients make one call instead of twelve.
• Service discovery: instances register in a registry (Consul, Eureka, or Kubernetes DNS) so callers find live endpoints without hard-coded IPs.
• Saga: replaces the distributed ACID transaction. A business operation becomes a sequence of local transactions, each publishing an event that triggers the next; failure triggers compensating transactions that semantically undo prior steps. Two flavors: choreography (services react to each other's events, no coordinator) and orchestration (a central orchestrator commands each step).
• CQRS + Event Sourcing: separate the write model from read models; rebuild queryable views by replaying an event log — the answer to "I can't JOIN across databases anymore."
• Resilience: Circuit Breaker stops hammering a dead dependency, bulkhead isolates thread pools so one slow service can't drain all threads, and timeouts + retries with jitter prevent cascading failure.
• Sidecar / Service Mesh: a proxy (Envoy) deployed beside each service handles mTLS, retries, and telemetry, moving cross-cutting concerns out of application code.

3. Worked scenario: an e-commerce checkout

Say Checkout peaks at 3,000 QPS on Black Friday. In a monolith, one "place order" call would be a single ACID transaction: reserve inventory, charge card, write order — all-or-nothing. Split into services, that atomicity is gone, so we run an orchestrated saga:

• Step 1 — Orders writes an order in PENDING (local txn, ~5 ms) and emits OrderCreated.
• Step 2 — Inventory reserves 2 units (~8 ms), emits StockReserved.
• Step 3 — Payments calls Stripe (~250 ms, the tail dominates). On success it emits PaymentCaptured; Orders flips to CONFIRMED.

If Stripe declines, the saga runs compensations in reverse: Inventory releases the 2 units, Orders marks the order CANCELLED. Note the window where inventory is reserved but payment hasn't cleared — the system is eventually consistent, not instantly. The API Gateway aggregates the customer's home page (orders + recommendations + cart) into one response; a circuit breaker on Recommendations means that if it exceeds a 200 ms timeout on >50% of calls, the gateway trips and serves a cached fallback instead of letting a slow service stall the whole page.

4. Trade-offs — when to use, when not

Versus the Monolith. A well-structured monolith gives you ACID transactions, refactoring across boundaries in one commit, one thing to deploy and trace, and zero network latency between components. Reach for microservices only when specific pains bite: (a) teams block each other on a shared release train, (b) parts of the system have wildly different scaling profiles (search vs. billing), or (c) the codebase is too large for any one person to hold. If you have 5 engineers, the monolith almost always wins — you'll pay the distributed-systems tax with none of the organizational payoff. Martin Fowler's guidance holds: start monolith-first, extract services when boundaries prove stable.

Versus the Modular Monolith. The underrated middle. Enforce module boundaries and separate schemas inside one deployable. You keep in-process transactions and one deploy while getting clean seams you can later cut into services. Choose this when you want microservices' modularity without the operational cost — it is the right default for most growing teams.

Choreography vs. Orchestration saga. Choreography (event reactions) is loosely coupled and great for 2–3 steps, but with 6+ services the flow becomes impossible to reason about — no one place tells the whole story. Orchestration centralizes the logic (easier to debug, visualize, and add steps) at the cost of a coordinator that must itself be resilient. Pick orchestration once flows get complex.

5. Pitfalls an interviewer probes

• Distributed monolith: services that must deploy together and call each other synchronously in long chains. You paid the network tax and kept the coupling — the worst of both worlds. Probe: "Can each service deploy independently?"
• Shared database: two services reading each other's tables. This silently recreates coupling and breaks independent schema evolution. Database-per-service is non-negotiable; expose data via APIs or events.
• "Just retry": naive retries without idempotency keys double-charge cards, and without jitter cause retry storms that DDoS your own backend. Every saga step must be idempotent.
• Ignoring the CAP/consistency reality: claiming a saga is "transactional." It is not — it's eventually consistent with a visible intermediate window. Know where you accept staleness.
• Chatty aggregation / N+1 across the network: rendering one page with 50 sequential service calls. Fix with a BFF, batching, or CQRS read models.
• No distributed tracing: without correlation IDs (OpenTelemetry, Jaeger), a single failed request across 8 services is undebuggable. Observability is a prerequisite, not an add-on.

Key takeaways

• Microservices trade simplicity for independent deployability and scaling — adopt them for organizational and scaling pain, not for fashion; a modular monolith is the smart default until the seams prove stable.
• Database-per-service forces you to replace distributed ACID transactions with sagas (choreography for simple flows, orchestration for complex ones) and to accept eventual consistency.
• Resilience is mandatory: circuit breakers, bulkheads, timeouts, idempotent + jittered retries, and a service mesh keep one slow dependency from cascading into a full outage.
• The classic interview trap is the distributed monolith — services that share a database or must deploy in lockstep — which pays every cost of distribution and gains none of the benefits.