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. Drawing boundaries — decomposition and Conway's Law

Splitting by business capability means each service maps to a coherent thing the business does: Orders, Payments, Inventory, Shipping. Each owns its data exclusively and exposes an API or events. Splitting by technical layer — a "controllers service," a "business-logic service," a "database service" — is the distributed-monolith anti-pattern: a single user action now fans across three services that must change and deploy together.

The concept from domain-driven design is the bounded context: a boundary inside which a model is consistent and unambiguous, and outside which other models may use different terms and rules. Product means something different in Catalog (what a customer sees) than in Inventory (SKU-level stock) than in Pricing (promotions and currency). Putting all three in one service forces a single, brittle model; splitting them accepts that each context has its own truth.

Conway's Law makes this organizational: a system's structure mirrors the communication structure of the organization. If three teams own one service, they still coordinate every change; if one team owns six tightly-coupled services, they deploy in lockstep. The Inverse Conway Maneuver is to design the desired architecture and then shape teams to match it, so the org naturally produces loose service boundaries.

Worked boundary decision. In an e-commerce platform, do Reviews belong with Catalog or with Orders? If reviews are primarily product-page enrichment and the catalog team ships them, keep them near Catalog. If reviews are tied to verified purchases, returns, and buyer reputation, they may belong closer to Orders. There is no universally right answer — the right answer is the one that aligns with the team that changes the feature and the data that defines its consistency boundary.

4. Inter-service communication — sync vs async

Every cross-service call is a choice between two shapes:

• Synchronous (REST/gRPC) — the caller blocks until the callee responds. Use it when the caller needs the answer to proceed and the callee is fast and reliable. REST is the default for broad interoperability; gRPC is better inside a homogeneous fleet where binary payloads and strong contracts matter. The cost is availability coupling: a chain of N sync calls multiplies availabilities (roughly A₁ × A₂ × … × Aₙ) and adds latencies.
• Asynchronous (message queue / event stream) — the caller publishes a message and returns immediately. Use it for fan-out, absorbing bursts, or when the producer must not care whether a consumer is healthy. A message queue (RabbitMQ, SQS) hands each message to one consumer in a pool; an event stream (Kafka) keeps a durable, ordered log that many independent consumer groups can read at their own pace and replay. The cost is eventual consistency and mandatory idempotency: at-least-once delivery is the only realistic guarantee, so consumers must deduplicate.

Typical checkout mix. The mobile app calls POST /orders through the API Gateway synchronously; the gateway routes to the orders service, which calls payments synchronously to authorize the card. Once the order is confirmed, the orders service publishes OrderPlaced to Kafka. Email, analytics, warehouse, and fraud-scoring each consume that event asynchronously in their own consumer group. Sync for the human waiting; async for everything else.

5. Observability — the prerequisite nobody skips successfully

Before you split a system, you need to be able to answer "what happened to request X?" across services. That requires three pillars and one discipline:

• Metrics — request rate, error rate, latency histograms per service and endpoint. These tell you whether a service is healthy in aggregate.
• Logs — centralized, queryable, and tagged with a correlation ID that is generated at the edge and propagated through every sync call and async message so all log lines for one request can be joined.
• Traces — per-request spans showing time spent in the gateway, each service, database, and external call. A trace turns "checkout is slow" into "the payment service's p99 jumped from 50 ms to 400 ms at 14:02."
• SLIs and SLOs — explicit reliability targets (e.g., checkout p99 < 200 ms, error rate < 0.1%). Without them, every blip feels like an incident.

Without observability, microservices are just a black box with more seams. With it, the seams become debuggable.

6. 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.

7. 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.

Worked example: e-commerce bounded contexts

Splitting by business capability means each context owns its own model, data, and invariants. Here is how four e-commerce contexts differ even though they all touch "the product":

Why not merge them? In Catalog, Product is a customer-facing entity with SEO fields. In Inventory, the same product is a SKU with warehouse bins. In Pricing, it is a priceable item under promotions. A single service forced to model all three becomes a tug-of-war: a pricing schema change breaks catalog deploys, and an inventory locking change slows product-page reads. Bounded contexts accept that the same real-world thing has legitimately different models on each side of the boundary.

A checkout flow across the boundaries. (1) The app fetches product details from Catalog and a price from Pricing synchronously for the human. (2) It calls Inventory to reserve stock. (3) On payment success it publishes OrderPlaced; Shipping consumes it and creates a shipment. Sync where the user waits; async where eventual consistency is acceptable.

Sync vs async decision table

Interview move: do not answer "REST or Kafka?" Answer "sync for the user-facing path with a timeout and circuit breaker; async for everything else; and always say what breaks when the downstream fails."

Observability prerequisite checklist

Before you split the first service out of a monolith, every one of these should be in place or budgeted. Without them, microservices are just a distributed debugging nightmare.

• Correlation IDs. Generated at the edge and propagated through every sync header and async message so a single request's logs can be joined across services.
• RED metrics per service. Request rate, error rate, and duration histograms (p50/p99) per endpoint.
• Centralized logs. Structured, queryable, and indexed by correlation ID, service, and trace.
• Distributed traces. Spans across gateway, services, databases, caches, and external calls; sampling that keeps cost sane while capturing errors.
• SLOs and error budgets. Explicit targets (e.g., checkout p99 < 200 ms, error rate < 0.1%) so teams agree on "good enough" before an outage defines it.
• Alerting and runbooks. Pages tied to symptoms (error-rate spike, latency jump), not just machine metrics; every alert links to a runbook.
• Service dependency map. A living diagram or generated graph showing who calls whom; the first incident will require it.

Check this list before the architecture review. A candidate who names sagas and circuit breakers but cannot say how they will know a saga failed has missed the prerequisite.

8. 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.