Microservices Architecture — DDL Lock Crashed 5 Services

Every company that has scaled past a certain size has hit the same wall: the monolith becomes unmaintainable. A change to the payment logic requires a full deployment of the entire application. One memory leak in the recommendation engine takes down the checkout flow. A single team of 200 engineers all committing to the same codebase creates merge conflicts, broken builds, and release bottlenecks that kill velocity. Netflix, Amazon, Uber, and Spotify all hit this wall and made the same architectural pivot — they decomposed their systems into microservices, and it changed how the entire industry thinks about building software at scale.

Microservices solve a specific, painful problem: the coupling problem. In a monolith, components share memory, share a database, and share a deployment lifecycle. That shared fate is the enemy of scale and resilience. Microservices decouple those dimensions — each service owns its data, deploys independently, scales independently, and fails independently. When the recommendation service goes down, users can still check out. When checkout traffic spikes on Black Friday, you scale just that service, not the entire application.

By the end of this article you'll understand not just what microservices are, but how to decompose a domain correctly using bounded contexts, which communication patterns to choose and why, how to handle distributed failure gracefully with circuit breakers and bulkheads, and the production-level trade-offs nobody talks about until it's 2am and your pager is going off. This is the article you read before your next system design interview — and before you propose microservices to your team.

What Is Microservices Architecture?

Microservices architecture breaks an application into small, loosely coupled services that each handle a specific business function. Each service runs its own process, communicates over a network, and can be deployed, scaled, and maintained independently. It's not about size — it's about autonomy. A single service might be 50 lines or 50,000 lines; what matters is that it owns its domain end-to-end and can be changed without asking permission from every other team.

The contrast with a monolith is worth making concrete. In a monolith, the order module and the payment module share the same JVM process. A method call from order to payment is a function invocation — nanoseconds, no network, no serialization. In a microservices system, that same interaction crosses a network boundary. It involves HTTP or gRPC, serialization, a timeout budget, and a retry policy. That cost is real, and it is worth paying only when the decoupling benefit justifies it.

Why does it matter? Because the monolith doesn't scale in two distinct ways that often get conflated. First, technical scaling: you cannot scale just the bottleneck. If your payment processing is slow and your product catalog is fine, a monolith forces you to scale both. Second, organizational scaling: with a monolith, every change requires coordination across the entire team. A 200-person engineering organization committing to a single codebase is a coordination disaster. Microservices give each team a codebase they can change and deploy without a cross-team meeting.

One thing I've seen consistently across migrations: the teams that succeed with microservices treat it as an organizational change first and a technical change second. The services that fail — the ones that create more meetings than they eliminate — are almost always the ones where the team structure didn't change when the codebase did.

package io.thecodeforge.microservices.boundary;

// ── What a monolith looks like: direct in-process method call ─────────────────
// Fast (nanoseconds), simple, but tightly coupled.
// A change to PaymentService requires redeploying the entire application.
// A crash in PaymentService brings down OrderService too — shared JVM process.
class MonolithOrderFlow {
    private final PaymentService paymentService;   // direct reference, same JVM
    private final InventoryService inventoryService;

    public OrderResult placeOrder(OrderRequest request) {
        // In-process call — no network, no serialization, no timeout
        PaymentResult payment = paymentService.charge(request.amount(), request.card());
        inventoryService.reserve(request.items());
        return new OrderResult(payment.transactionId());
    }
}

// ── What the same flow looks like as microservices ────────────────────────────
// Each service is a separate process, potentially on a different machine.
// OrderService does NOT hold a reference to PaymentService — it makes a network call.
// The cost: network latency (~1–5ms same cluster), serialization, timeout budget.
// The benefit: PaymentService can be deployed, scaled, and failed independently.
class MicroserviceOrderFlow {
    private final PaymentClient paymentClient;       // HTTP/gRPC client, not a direct ref
    private final InventoryClient inventoryClient;
    private final EventPublisher eventPublisher;

    public OrderResult placeOrder(OrderRequest request) {
        // Network call — PaymentService is a separate deployed process
        // If PaymentService is slow, only this thread blocks — not the entire application
        PaymentResult payment = paymentClient.charge(request.amount(), request.card());

        // Async event — InventoryService consumes this when it's ready
        // OrderService does not wait for inventory to confirm — decoupled in time
        eventPublisher.publish(new OrderPlacedEvent(request.orderId(), request.items()));

        return new OrderResult(payment.transactionId());
    }
}

// ── The key trade-off in one line ─────────────────────────────────────────────
// Monolith:      fast, simple, coupled — one failure domain
// Microservices: slower, complex, decoupled — isolated failure domains
// Choose based on team size and scaling bottleneck, not on what's fashionable.

Service Decomposition — The Bounded Context Rule

The hardest part of microservices isn't the technology — it's deciding where to cut. Most teams get this wrong by splitting services along technical layers: a database service, a UI service, a middleware service. That creates a distributed monolith: every business feature still touches all three services and requires coordinated deployment. The correct approach is Domain-Driven Design's bounded context: each microservice models a single business capability, owns all the data and logic for that capability, and communicates with other services via explicit interfaces.

For an e-commerce system, that means separate services for Product Catalog, Order Management, Payment, Inventory, and Shipping. Not a 'backend service' and a 'frontend service'. Each bounded context has its own database schema, its own deployment pipeline, and ideally its own team. The boundaries are driven by the business domain, not the technical stack.

The most useful heuristic I know: if two pieces of functionality change for the same business reason, they belong in the same service. If they change for different reasons — different teams, different stakeholders, different release cadences — they should be separated. This is the Single Responsibility Principle applied at the service level rather than the class level.

Event storming is the most effective technique for finding these boundaries in practice. Get domain experts, engineers, and product managers in a room. Write business events on sticky notes (OrderPlaced, PaymentFailed, ItemShipped). Group the events by the business process they belong to. Those groups are your bounded contexts. The boundaries where events cross between groups are where your service APIs will live.

Let's be honest about something: you will get the boundaries wrong the first time. Domain knowledge accretes over years, and the first cut is always made with incomplete information. That is acceptable — as long as each service has its own data and its own deployment pipeline, merging two services is a manageable refactor. The cost of merging two over-split services is much lower than the cost of untangling a prematurely split service that shares a database with its neighbor.

Use the strangler fig pattern when extracting services from an existing monolith: route specific request types to the new service while the monolith handles everything else, then gradually expand the new service's responsibility until the monolith no longer handles that capability. Never attempt a big-bang rewrite — extract one bounded context at a time, validate it in production, then move to the next.

package io.thecodeforge.microservices;

// OrderService owns the Order bounded context entirely.
// It knows about orders, order lifecycle events, and order state.
// It does NOT know about inventory levels, payment processing details,
// or shipping logistics — those belong to other bounded contexts.
//
// The service's API surface is what it publishes to other services:
//   - Events: OrderCreatedEvent, OrderCancelledEvent, OrderFulfilledEvent
//   - Queries: getOrder(orderId), listOrdersByUser(userId)
//
// Nothing outside this service queries the orders table directly.
// That boundary is what makes independent deployment possible.
public class OrderService {
    private final OrderRepository orderRepository;
    private final EventPublisher eventPublisher;

    public OrderService(OrderRepository orderRepository, EventPublisher eventPublisher) {
        this.orderRepository = orderRepository;
        this.eventPublisher = eventPublisher;
    }

    public Order createOrder(CreateOrderRequest request) {
        // OrderService validates and persists the order.
        // It does NOT call InventoryService or PaymentService synchronously here.
        // Those services will react to the OrderCreatedEvent asynchronously.
        // This means: order creation never blocks on inventory availability.
        Order order = new Order(
            request.userId(),
            request.items(),
            request.shippingAddress(),
            OrderStatus.PENDING
        );
        orderRepository.save(order);

        // Publish the event — other bounded contexts react at their own pace.
        // PaymentService will attempt to charge. InventoryService will reserve stock.
        // If either fails, they publish their own compensating events.
        eventPublisher.publish(new OrderCreatedEvent(
            order.id(),
            order.userId(),
            order.items(),
            order.shippingAddress(),
            order.totalAmount()
        ));

        return order;
    }

    public Order getOrder(String orderId) {
        // Other services that need order data call this method via REST/gRPC.
        // They do NOT query the orders table directly.
        return orderRepository.findById(orderId)
            .orElseThrow(() -> new OrderNotFoundException(orderId));
    }
}

Communication Patterns — Sync vs Async

Microservices need to talk to each other. The two dominant patterns are synchronous (HTTP/REST, gRPC) and asynchronous (message queues, event streaming). Each comes with trade-offs that are not symmetric — choosing the wrong one for a given interaction is one of the most common causes of production incidents in microservices systems.

Synchronous calls are simple to implement and reason about: service A calls service B, waits for a response, and returns it to the caller. But they introduce tight temporal coupling. If service B is slow, service A blocks. If service B is down, service A fails. A chain of five synchronous hops means five points of failure, and the latencies add up: 5ms per hop becomes 25ms minimum for a request that touches five services, and under load that can easily become 250ms. Thread pool exhaustion is the failure mode — service B holding 200ms responses consumes all of service A's worker threads, and service A starts returning 503 to its callers before service B actually goes down.

Asynchronous communication decouples services in time: service A publishes an event to a message broker (Kafka, RabbitMQ, AWS SQS) and continues executing without waiting. Service B consumes the event when it is ready. If service B is slow, the message queue absorbs the backlog. If service B restarts, it picks up where it left off. The caller's latency is near zero — publishing a message to Kafka takes microseconds. But you have accepted eventual consistency. The caller cannot know the outcome of the operation immediately. You now manage topics, consumer groups, dead-letter queues, and message schema evolution.

gRPC deserves a specific mention for synchronous calls. It uses HTTP/2 (multiplexed connections, header compression, binary framing) and Protocol Buffers (compact binary serialization). For internal service-to-service calls where both sides are controlled, gRPC typically outperforms REST by 5x to 10x in throughput and 30% to 50% in latency at the same load. The cost is tooling complexity — you need protobuf schema management and a gRPC gateway if browser clients need access. For high-throughput internal APIs in 2026, gRPC is the default choice; REST is for external-facing APIs where developer experience and wide tooling support matter more than raw performance.

The rule that holds in production: default to async for most interactions, especially when the calling service does not need an immediate result. Use sync only when you truly need a real-time, consistent response — payment authorization, user authentication, read queries where the client is waiting. Even for synchronous calls, always set explicit timeouts. A downstream that never responds is worse than one that responds with an error, because it holds your thread indefinitely.

package io.thecodeforge.microservices.event;

import io.thecodeforge.microservices.OrderCreatedEvent;

// InventoryEventHandler is completely decoupled from OrderService.
// OrderService does not know InventoryService exists.
// InventoryService does not know when OrderService deployed last.
// They are connected only by the shape of the OrderCreatedEvent message.
//
// This is the async pattern in practice:
//   - OrderService publishes → returns immediately (no wait)
//   - Kafka durably stores the event
//   - InventoryService consumes at its own pace
//   - If InventoryService is down: event waits in Kafka (retention: configurable, default 7 days)
//   - When InventoryService restarts: it processes the backlog
//   - No data loss, no cascading failure into OrderService
public class InventoryEventHandler {
    private final InventoryService inventoryService;
    private final DeadLetterPublisher deadLetterPublisher;

    public InventoryEventHandler(InventoryService inventoryService,
                                  DeadLetterPublisher deadLetterPublisher) {
        this.inventoryService = inventoryService;
        this.deadLetterPublisher = deadLetterPublisher;
    }

    // Called by the Kafka consumer when an OrderCreatedEvent arrives.
    // This method must be idempotent — Kafka delivers at-least-once,
    // so this handler may be called more than once for the same event.
    // Use the orderId as an idempotency key to detect and skip duplicates.
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            for (var item : event.items()) {
                // idempotent: reserve does nothing if already reserved for this orderId
                inventoryService.reserve(item.sku(), item.quantity(), event.orderId());
            }
        } catch (InsufficientStockException e) {
            // Business failure — do not retry. Publish to DLQ for manual review
            // and publish a StockUnavailableEvent so OrderService can compensate.
            deadLetterPublisher.publish(event, e.getMessage());
            // The saga compensation: OrderService will cancel the order when it
            // receives StockUnavailableEvent.
        } catch (TransientException e) {
            // Transient failure (DB timeout, network blip) — rethrow so Kafka retries
            // with the consumer's configured retry policy and backoff.
            throw e;
        }
    }
}

Failure Isolation — Circuit Breakers, Bulkheads, and Retry

In a microservices architecture, failure is not an edge case — it is the normal operating condition at scale. Services crash, networks partition, databases slow down, and dependencies time out. Without explicit isolation patterns, a single failing service can exhaust upstream thread pools and cascade failures through your entire system within seconds. These patterns are not optional features you add when something breaks — they are the load-bearing walls of a resilient distributed system.

The three essential patterns work together:

A circuit breaker monitors the error rate on calls to a downstream service. When errors exceed a configured threshold (say, 50% of calls failing in a 10-second window), the breaker opens: subsequent calls fail immediately without touching the downstream. After a cooldown period, the breaker enters half-open state and allows a single test call through. If the test succeeds, the breaker closes and normal traffic resumes. If it fails, the breaker reopens for another cooldown. The critical benefit: thread pools stop being consumed by calls that will time out anyway, and the failing downstream gets time to recover without being hammered by a thundering herd.

A bulkhead isolates resource consumption so that a failure in one dependency cannot consume all available threads or connections. In practice: separate thread pools (or semaphore-based concurrency limits) for each downstream dependency. If your payment service is slow and consuming all threads in its pool, calls to your product catalog service still have their own pool to use. The payment slowness is contained. Without bulkheads, one slow downstream starves every other dependency simultaneously.

Retry with exponential backoff handles transient failures — network blips, temporary overload, brief restarts. The key word is exponential: first retry after 200ms, second after 400ms, third after 800ms, with jitter added to prevent synchronized retry storms when hundreds of clients retry simultaneously. Never retry without backoff. Never retry more than three times for most operations.

The correct decorator order matters and is a common implementation mistake: the circuit breaker must wrap the retry, not the other way around. If retry wraps the circuit breaker, every retry hits the open breaker and generates another failure count. If the circuit breaker wraps the retry, an open breaker short-circuits before any retry fires — which is the correct behavior.

Timeouts are the cheapest isolation mechanism and the one most often forgotten. A downstream that never responds is worse than one that responds with an error — it holds your thread indefinitely. Set explicit timeouts on every network call. In Resilience4j, configure TimeLimiter alongside your circuit breaker. In gRPC, set deadlines on every RPC. A reasonable starting point: 200ms for internal calls on the same cluster, 1 second for calls crossing availability zones.

Don't treat these as separate decisions. The production-proven combination is: timeout (cheapest, first line) + retry with backoff (transient failures) + circuit breaker (persistent failures) + bulkhead (resource isolation). Each one handles a different failure mode. Together they give you a system that degrades gracefully under partial failure rather than failing completely.

package io.thecodeforge.microservices.resilience;

import io.github.resilience4j.circuitbreaker.CircuitBreaker;
import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig;
import io.github.resilience4j.retry.Retry;
import io.github.resilience4j.retry.RetryConfig;
import io.github.resilience4j.timelimiter.TimeLimiter;
import io.github.resilience4j.timelimiter.TimeLimiterConfig;
import java.time.Duration;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.function.Supplier;

public class ResilientPaymentClient {

    // ── Bulkhead: dedicated thread pool for payment calls ─────────────────────
    // Payment slowness consumes only THESE threads.
    // Product, inventory, and shipping calls use their own pools.
    // Without this: one slow dependency starves all others.
    private final ExecutorService paymentThreadPool = Executors.newFixedThreadPool(10);

    // ── Timeout: 300ms hard limit on payment calls ────────────────────────────
    // A payment service that never responds is worse than one returning errors.
    // Without this: threads block indefinitely, pool exhausts, system fails.
    private final TimeLimiter timeLimiter = TimeLimiter.of(
        TimeLimiterConfig.custom()
            .timeoutDuration(Duration.ofMillis(300))
            .build()
    );

    // ── Retry: up to 3 attempts for transient failures ────────────────────────
    // Handles network blips and brief restarts.
    // Exponential backoff with jitter prevents thundering herd on recovery.
    // Only retries on transient exceptions — not on business logic failures.
    private final Retry retry = Retry.of("payment",
        RetryConfig.custom()
            .maxAttempts(3)
            .waitDuration(Duration.ofMillis(200))
            .retryExceptions(TransientPaymentException.class)
            .ignoreExceptions(PaymentDeclinedException.class)  // business failure, don't retry
            .build()
    );

    // ── Circuit Breaker: opens when 50% of calls fail in 10s window ───────────
    // Prevents thread pool exhaustion during persistent downstream failures.
    // After 30s cooldown, allows one test call (half-open) to check recovery.
    private final CircuitBreaker circuitBreaker = CircuitBreaker.of("payment",
        CircuitBreakerConfig.custom()
            .failureRateThreshold(50)            // open if 50% of last 10 calls fail
            .waitDurationInOpenState(Duration.ofSeconds(30))  // cooldown before half-open
            .permittedNumberOfCallsInHalfOpenState(2)         // test calls in half-open
            .slidingWindowSize(10)
            .build()
    );

    // ── Decorator order: circuit breaker WRAPS retry ──────────────────────────
    // If retry wrapped circuit breaker:
    //   open breaker → retry fires → hits open breaker again → counts as failure
    //   → keeps breaker open even after downstream recovers (wrong)
    //
    // Circuit breaker wrapping retry (correct):
    //   open breaker → fails immediately, no retry fires
    //   closed breaker → retry handles transient failures within the closed state
    public CompletableFuture<PaymentResponse> charge(PaymentRequest request) {
        Supplier<PaymentResponse> supplier =
            CircuitBreaker.decorateSupplier(circuitBreaker,
                Retry.decorateSupplier(retry,
                    () -> callPaymentService(request)
                )
            );

        // Combine timeout + bulkhead: supplier runs in dedicated pool with hard deadline
        return timeLimiter.executeCompletionStage(
            paymentThreadPool,
            () -> CompletableFuture.supplyAsync(supplier, paymentThreadPool)
        ).toCompletableFuture();
    }

    private PaymentResponse callPaymentService(PaymentRequest request) {
        // actual gRPC or HTTP call to payment service
        throw new UnsupportedOperationException("implement with actual gRPC client");
    }
}

Observability — Distributed Tracing, Structured Logging, and Metrics

You cannot debug what you cannot see. In a monolith, a single log file and a profiler were enough. In a microservices system, a single user request may travel through ten services across fifty containers. Standard logging gives you noise — you see errors in service A but cannot tell which upstream request caused them or which downstream call caused the delay. Centralized metrics tell you something is wrong but not where. Without proper observability, you are debugging a distributed system with a flashlight.

The three pillars work together, and the key is understanding which tool answers which question:

Distributed tracing answers the question 'what happened to this specific request?' Every request receives a unique trace ID at the entry point. That ID propagates — via HTTP headers, Kafka message headers, or gRPC metadata — through every service the request touches. Each service creates a span (a unit of work with start time, end time, and metadata) and attaches it to the trace. The result is a waterfall view of the entire request path: you can see that the checkout request spent 2ms in order service, 180ms waiting for a payment service response, and 4ms in the shipping service. The bottleneck is obvious.

In 2026, the instrumentation standard is OpenTelemetry. It is vendor-neutral, language-agnostic, and supported natively by every major cloud provider and observability vendor. You instrument your services once with the OpenTelemetry SDK and choose a backend separately. Jaeger and Grafana Tempo are the dominant self-hosted backends. Honeycomb, Datadog, and Grafana Cloud are the managed options. Do not confuse OpenTelemetry (the instrumentation layer) with the backend (the storage and query layer) — they are separate concerns. Choose OpenTelemetry for instrumentation regardless of which backend you use.

A critical implementation detail: context propagation across async boundaries. When an HTTP request handler publishes a Kafka message and returns, the trace context must be serialized into the Kafka message headers. When the consumer picks up that message, it must extract the trace context and continue the same trace. The OpenTelemetry Kafka instrumentation handles this automatically if you use the provided producer and consumer wrappers. If you use a custom producer, you must manually inject the context using W3C Trace Context headers. Miss this step and your traces fragment at every async boundary — you see half a trace on the HTTP side and a disconnected trace on the consumer side.

Structured logging answers 'what was this service doing at this time?' Log as JSON with a consistent schema: timestamp, level, service name, trace_id, span_id, message, and any business context (order_id, user_id). The trace_id field is what ties your logs to your traces — when a slow span appears in Jaeger, you copy the trace_id and filter your log aggregator (Grafana Loki, ELK) to see every log line from every service for that specific request.

Metrics answer 'is the system healthy right now?' Instrument every service with RED metrics: Rate (requests per second), Errors (error rate as a percentage), and Duration (latency distribution — p50, p95, p99). Use Prometheus to scrape and Grafana to alert. Alert on p99 latency and error rate, not on individual error logs. One error log is noise; a sustained 5% error rate is an incident.

The workflow that works in production: an alert fires on p99 latency for checkout. You open the Grafana dashboard and see the latency spike started four minutes ago. You jump to Jaeger and filter for slow traces in the checkout service from that window. You find a trace where the payment span took 2.8 seconds instead of the usual 180ms. You copy the trace_id, filter Loki for that ID, and see the payment service logs show a database connection timeout. Root cause found in under five minutes. Without tracing, this investigation takes hours.

// Structured log entry from order-service during a payment failure.
// Every field is queryable in Loki/Elasticsearch — no grep through prose.
// The trace_id ties this log line to the distributed trace in Jaeger/Tempo.
// The span_id identifies this specific unit of work within the trace.
// A developer sees the error alert, filters Loki by trace_id, and gets
// every log line from every service for this one request — instantly.
{
  "timestamp": "2026-04-22T10:30:15.123Z",
  "level": "ERROR",
  "service": "order-service",
  "version": "2.14.1",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "message": "payment_charge_failed",
  "order_id": "ord-98765",
  "user_id": "usr-4421",
  "amount_cents": 4999,
  "error": {
    "type": "ServiceUnavailable",
    "code": "PAYMENT_CIRCUIT_OPEN",
    "downstream": "payment-service",
    "duration_ms": 301,
    "retry_attempts": 3
  },
  "action_taken": "order_held_pending_payment_recovery"
}

// What you can query with this structure (Loki LogQL examples):
//
// All errors for a specific order:
//   {service="order-service"} | json | order_id="ord-98765" | level="ERROR"
//
// All log lines across ALL services for one user request:
//   {} | json | trace_id="4bf92f3577b34da6a3ce929d0e0e4736"
//
// Payment failures in the last 5 minutes:
//   {} | json | message="payment_charge_failed" | rate() > 10
//
// Without structured logging and trace_id propagation:
//   grep -r "ord-98765" /var/log/*  ← across 10 services, 50 containers
//   ... good luck

Data Ownership and Database-Per-Service

One of the biggest shifts when moving from monolith to microservices is data management. In a monolith, all components share one database — easy to query across entities with joins, but impossible to decouple. In microservices, each service must own its data exclusively: its own database instance, its own schema, credentials that no other service can use. This is the rule that most teams resist and most teams eventually learn the hard way.

Why does it matter? A shared database creates the worst kind of coupling: schema coupling. If two services read from the same table, you cannot change that table without coordinating across both teams. A migration becomes a multi-service, multi-team deployment. A slow query from one service exhausts connection pools that another service depends on. A metadata lock from a DDL operation on one service brings down queries from every other service on that database server. You get all the operational complexity of microservices — distributed deployment, network calls, serialization — with none of the independence.

But what happens when Service A needs data that Service B owns? This is the question teams ask when they first encounter the database-per-service rule, and the answer has two parts.

For real-time queries where Service A needs current data from Service B: use an API call. Service A calls Service B's REST or gRPC endpoint. This adds latency (a network hop) but maintains the boundary. If the data is read frequently and changes infrequently, cache it locally in Service A with a TTL. Service A caches Service B's data for 60 seconds — staleness is bounded, and Service A's availability is no longer coupled to Service B's.

For analytics queries, reporting, and cases where Service A needs data from multiple services combined: use the CQRS pattern with a read model. Each service publishes its state changes as events. A read service (sometimes called a query service or materialized view service) consumes those events and maintains a denormalised projection optimised for the query patterns you need. You can run cross-service joins on this read model because it is a dedicated view, not the source of truth. The source of truth for each entity remains in the owning service's database.

Data duplication across services via events is not a bug — it is a deliberate design decision that buys you deployment independence. The shipping service maintains its own copy of the order's shipping address, derived from the OrderCreatedEvent, because it cannot afford to call the order service every time it needs that address. If the order service is down, shipments must still be processable. Accept the duplication. The alternative — shared database — is far more expensive when it breaks.

package io.thecodeforge.microservices.data;

import io.thecodeforge.microservices.event.OrderCreatedEvent;
import java.util.List;
import java.util.stream.Collectors;

// ShippingService owns the shipping_info table.
// It has ZERO knowledge of the orders table — that is OrderService's domain.
// It does NOT query OrderService's database directly.
// It does NOT call OrderService's API to get shipping information.
//
// Instead: it consumes the OrderCreatedEvent, which contains enough data
// for ShippingService to do its job without ever talking to OrderService again.
//
// This means:
//   - ShippingService can be deployed without OrderService being up
//   - ShippingService can be scaled without affecting OrderService
//   - OrderService can change its internal data model without affecting ShippingService
//     (as long as the event schema remains backward-compatible)
public class ShippingService {
    private final ShippingRepository shippingRepository;

    public ShippingService(ShippingRepository shippingRepository) {
        this.shippingRepository = shippingRepository;
    }

    // Consumes OrderCreatedEvent — called by the Kafka consumer.
    // The event payload contains all data ShippingService needs.
    // This is deliberate data duplication: the shipping address exists in
    // both the orders table (OrderService) and shipping_info table (ShippingService).
    // That duplication is the price of independence. It is worth it.
    public void handleOrderCreated(OrderCreatedEvent event) {
        List<String> skus = event.items().stream()
            .map(item -> item.sku())
            .collect(Collectors.toList());

        ShippingInfo info = new ShippingInfo(
            event.orderId(),
            event.shippingAddress(),   // copied from event — ShippingService owns this copy
            skus,
            ShippingStatus.PENDING
        );
        shippingRepository.save(info);
        // ShippingInfo is now persisted in ShippingService's own database.
        // If OrderService goes down 5 minutes later: ShippingService continues
        // processing shipments from its own data store.
    }

    // When another service needs shipping data: they call this API.
    // They do NOT query ShippingService's database directly.
    public ShippingInfo getShippingInfo(String orderId) {
        return shippingRepository.findByOrderId(orderId)
            .orElseThrow(() -> new ShippingInfoNotFoundException(orderId));
    }
}

Organizational Alignment — Conway's Law in Practice

Conway's Law states that organizations which design systems are constrained to produce designs that mirror their own communication structures. It was observed in 1967 and has been validated by every large-scale software organization since. In practical terms: your system architecture will look like your org chart. If your teams are organized by technical function — a frontend team, a backend team, a database team — your architecture will produce a frontend service, a backend service, and a database service, regardless of what your technical documents say you are building. You do not choose whether Conway's Law applies. You only choose whether you use it deliberately.

The inverse also holds, and this is the actionable version: if you want a particular architecture, first build the org structure that produces it. Amazon's two-pizza team rule — no team larger than can be fed by two pizzas — predates their service-oriented architecture. The small team size was a deliberate design decision that forced service boundaries: a team can only own what it can fully understand and operate. The services emerged from the team constraints, not the other way around.

The failure mode I have seen most consistently in enterprise microservices migrations: a company decomposes its codebase into fifteen services but keeps the same five teams. Each team owns three services. The services are technically separate deployments, but the teams are not independent — a change to the payment flow still requires coordination between the checkout team and the payments team and the fraud team. Deployment calendars replace merge conflicts as the bottleneck. The coordination overhead is identical to the monolith, but now you also have distributed systems complexity. This is the worst possible outcome.

The fix is to reorganize around business capabilities before splitting the codebase. Each team should own one bounded context end-to-end: the code, the database, the deployment pipeline, the on-call rotation, and the runbooks. The team size should stay between five and nine people — large enough to have cross-functional skills (backend, frontend, data, ops), small enough to move fast without internal coordination overhead. When a team exceeds nine people, split it along sub-domain lines and create a new bounded context.

One practical technique: before any code is split, draw the target team structure and ask whether each team can write, test, deploy, and operate their service without scheduling a meeting with another team. If the answer is no for any team, the boundaries are wrong. Fix the org chart first, then split the code.

package io.thecodeforge.microservices.org;

// This file is not executable — it is a documentation artifact showing
// how team ownership maps to service ownership in a correctly aligned org.
//
// The rule: one team, one bounded context, one service (or a small cluster
// of tightly related services that always deploy together).
//
// ── WRONG: Technical layer teams ─────────────────────────────────────────────
// Team: Frontend    owns: checkout-ui, product-ui, account-ui
// Team: Backend     owns: checkout-api, product-api, account-api, order-api
// Team: Database    owns: all schema migrations across all services
//
// Result (Conway's Law, unavoidable):
//   - Every feature requires coordination across Frontend + Backend + Database
//   - The 'database team' becomes a bottleneck for every service's migrations
//   - Services cannot deploy independently because the database team controls schemas
//   - Architecture: layered monolith, distributed across three codebases
//
// ── CORRECT: Business capability teams ───────────────────────────────────────
// Team: Checkout (7 people)   owns: checkout-service, checkout DB, checkout UI components
// Team: Payments  (6 people)  owns: payment-service, payment DB, payment gateway integrations
// Team: Catalog   (8 people)  owns: product-service, catalog DB, search indexing
// Team: Orders    (6 people)  owns: order-service, order DB, order history UI
// Team: Shipping  (5 people)  owns: shipping-service, shipping DB, carrier integrations
//
// Result:
//   - Checkout team ships a feature without talking to Payments team
//     (they publish an OrderReadyForPayment event; Payments team owns the handler)
//   - Payments team deploys a new gateway integration without a change freeze
//   - Catalog team runs a schema migration on their own schedule
//   - Architecture mirrors the team structure — bounded contexts are clean

// The test for correct alignment: can this team respond to a production incident
// in their service at 2am without waking up another team?
// If yes: the boundary is correct.
// If no: the boundary is wrong — some dependency crosses team lines.

class TeamBoundaryValidator {
    public static boolean isBoundaryCorrect(Team team, Service service) {
        return team.canDeploy(service)           // team controls the pipeline
            && team.ownsDatabase(service)        // team owns the schema
            && team.respondsToAlerts(service)    // team is on-call for this service
            && team.size() >= 5                  // small enough to move fast
            && team.size() <= 9;                 // large enough to be cross-functional
    }
}