Microservices Architecture

Service Decoupling and Domain Decomposition

The fundamental premise of microservices is the decomposition of a system into bounded contexts. In a monolithic system, code is often tightly coupled through shared memory, leading to a 'big ball of mud' where changes in one domain accidentally break unrelated features. By isolating domains—such as Billing, Inventory, or User Profiles—into separate services, you force developers to think in terms of clear contracts rather than internal implementation details. This separation allows each service to evolve independently. When you design a microservice, you are essentially defining a boundary where the cost of communication over a network is justified by the gain in organizational agility and fault tolerance. Reasoning about this requires understanding that boundaries should align with business capabilities, not technical layers, ensuring that a change in the product requirement only impacts the specific service responsible for that business logic.

// A simple interface definition for a User Service interaction
interface UserProfile {
  id: string;
  email: string;
}

// The service acts as a black box that hides storage implementation
function getUser(userId: string): UserProfile {
  // In a real system, this would involve a network call or internal database lookup
  return { id: userId, email: "user@example.com" };
}

Inter-Service Communication Patterns

Since microservices run in isolation, they must exchange information over a network. The two primary patterns are synchronous Request-Response and asynchronous Event-Driven messaging. Synchronous patterns, like REST, are intuitive but create temporal coupling: if the service you call is down, your request fails. This makes the system fragile. Conversely, asynchronous communication using message queues allows services to operate independently. If an upstream service emits an event, the downstream service can consume it whenever it becomes available, effectively buffering traffic spikes and preventing cascading failures. When choosing between these, consider the latency requirements. Synchronous calls are best for read-heavy operations where immediate results are mandatory, while asynchronous messaging is superior for workflow orchestration and long-running processes where you can trade immediate consistency for increased availability and throughput across the entire distributed ecosystem.

// Simulating a message queue publisher to decouple services
const queue = [];

function publishEvent(eventType: string, payload: any) {
  // Decouples the producer from the consumer via a buffer
  queue.push({ eventType, payload, timestamp: Date.now() });
  console.log(`Event ${eventType} queued for processing.`);
}

Resilience Through Circuit Breakers

In a distributed system, failures are inevitable. A microservice might experience high latency or go offline entirely. If your service blindly keeps trying to call a failing dependency, it risks exhausting its own resources, like thread pools or connection sockets, leading to a total system collapse. A circuit breaker pattern prevents this. It acts as a safety switch: if failure rates exceed a defined threshold, the 'circuit' trips and the caller immediately returns an error or a fallback response without attempting the network request. After a timeout period, the breaker enters a 'half-open' state to test if the service has recovered. This mechanism is crucial for microservices because it limits the blast radius of a failure. By failing fast, you preserve the stability of the caller, allowing the rest of the system to continue functioning while the failing component is addressed or auto-heals.

let state = 'CLOSED'; // 'CLOSED', 'OPEN', 'HALF-OPEN'

function callRemoteService(request) {
  if (state === 'OPEN') return 'Fallback: Service Unavailable';
  
  try {
    // Execute request logic...
    return 'Success';
  } catch (e) {
    state = 'OPEN'; // Trip the breaker
    setTimeout(() => state = 'HALF-OPEN', 5000);
    return 'Fallback: Error handled';
  }
}

Data Management and Consistency

The most challenging aspect of microservices is managing data. In a monolith, you use ACID transactions across all tables. In microservices, every service owns its own database, making global transactions impossible. You must embrace eventual consistency. If a user update needs to propagate to multiple services, you use the Saga pattern: a sequence of local transactions where each step publishes an event to trigger the next. If a step fails, the system executes 'compensating transactions' to undo the changes made by previous steps. This is more complex than a standard database transaction, but it is necessary for maintaining system availability. You must reason about the 'state' of the system as a distributed property rather than a local one, ensuring that every service eventually reaches a consistent state even if they are temporarily out of sync during the process.

// A simplistic saga step executor for distributed consistency
async function executeOrderSaga(order) {
  try {
    await reserveInventory(order);
    await processPayment(order);
  } catch (e) {
    // Compensating transaction if payment fails
    await releaseInventory(order);
  }
}

Observability and Distributed Tracing

When a system is composed of dozens of services, debugging an error is difficult because a single user request might traverse multiple network hops. Traditional logging is insufficient here. You need distributed tracing, where each request is assigned a unique correlation ID that travels across every service boundary. This ID allows you to reconstruct the entire request path in a monitoring tool, showing where time was spent and where failures occurred. Without proper observability, a microservice architecture becomes a black box that is impossible to maintain. You must invest in centralizing logs, metrics, and traces early. Understanding the system's performance requires you to look at the 'golden signals': latency, traffic, errors, and saturation. By instrumenting your code to propagate trace headers, you gain the ability to pinpoint exactly which service in the chain is causing a bottleneck or a critical error.

// Attaching a trace ID to headers to monitor requests across services
function makeAuthenticatedCall(url, traceId) {
  const headers = { 'X-Trace-Id': traceId };
  // Using fetch to pass the trace information downstream
  return fetch(url, { headers });
}

Interview questions

All System Design interview questions →

Check yourself

Take the full System Design quiz →