Microservices Architecture

Microservices architecture is an approach to building software as a collection of small, independently deployable services, each owning a specific business capability and communicating over well-defined APIs.

What It Really Means

Instead of building one large application that handles everything — user authentication, order processing, payments, notifications — you decompose it into separate services. Each service runs its own process, manages its own data store, and can be developed, deployed, and scaled independently.

The defining characteristic is not size. It is independence. A microservice can be deployed without coordinating with other teams. It can be rewritten in a different language without affecting the rest of the system. It can scale horizontally based on its own traffic patterns. This independence enables organizational scaling — teams can own services end-to-end without stepping on each other.

Microservices emerged from real engineering constraints at companies like Netflix, Amazon, and Spotify. Amazon's famous "two-pizza teams" mandate in the early 2000s drove them to decompose their monolith into services that could be owned by small, autonomous teams. Netflix followed when their monolithic DVD rental application could not support the scale and velocity required for streaming. The pattern was formalized by James Lewis and Martin Fowler in 2014.

How It Works in Practice

Real System Example: E-Commerce Platform

Consider an e-commerce platform decomposed into microservices:

• User Service — authentication, profiles, preferences (PostgreSQL)
• Product Catalog Service — product listings, search, categories (Elasticsearch + PostgreSQL)
• Cart Service — shopping cart management (Redis)
• Order Service — order lifecycle, status tracking (PostgreSQL)
• Payment Service — payment processing, refunds (PostgreSQL + payment gateway)
• Notification Service — email, SMS, push notifications (message queue + third-party APIs)
• Inventory Service — stock levels, warehouse allocation (PostgreSQL)

Each service has its own database (database-per-service pattern), its own CI/CD pipeline, and its own team. The Cart Service uses Redis because it needs fast reads and writes for ephemeral session data. The Product Catalog Service uses Elasticsearch because it needs full-text search. Each service chooses the technology that fits its specific requirements.

Communication Patterns

Synchronous (REST/gRPC): The Order Service calls the Payment Service to charge a credit card and waits for the response. Use for operations that require an immediate result.

Asynchronous (Message Queues): When an order is placed, the Order Service publishes an OrderPlaced event to a message broker. The Notification Service, Inventory Service, and Analytics Service each consume this event independently. Use for operations that can happen eventually and should not block the user. See event-driven architecture for deeper coverage.

Service Discovery and Routing

Services need to find each other. In Kubernetes, DNS-based service discovery is built in — payment-service.default.svc.cluster.local resolves to the current instances. Outside Kubernetes, you use a service registry like Consul or Eureka. An API gateway handles external client routing, authentication, and rate limiting.

Implementation

Trade-offs

When to Use Microservices

• Multiple teams need to deploy independently with different release cadences
• Different parts of the system have vastly different scaling requirements
• You need technology diversity — different services benefit from different languages or databases
• The domain is well understood and service boundaries are clear
• Your organization has the operational maturity to manage distributed systems

When NOT to Use Microservices

• Small teams (fewer than 10 engineers) — the overhead outweighs the benefits
• New products where the domain is not well understood — you will draw the wrong boundaries
• When you lack observability, CI/CD, and container orchestration infrastructure
• When a monolith is performing well and the team is productive

Advantages

• Independent deployment enables faster release cycles per team
• Fault isolation — a crash in the Notification Service does not take down Order processing
• Technology flexibility — use the best tool for each job
• Scales with organizational growth — add teams without coordination overhead

Disadvantages

• Network calls replace function calls — latency, failure modes, serialization overhead
• Distributed transactions are hard — no more simple database transactions across services
• Operational complexity — you need logging, tracing, monitoring, and alerting across dozens of services
• Testing is harder — integration tests require multiple services running
• Data consistency requires careful design — eventual consistency is the norm

Common Misconceptions

• "Microservices are always better than monoliths" — Many successful companies run monoliths at scale. Shopify processes billions of dollars through a modular monolith. The right architecture depends on team size, domain maturity, and operational capability. See monolith vs microservices.

• "Each microservice should be as small as possible" — The name is misleading. The goal is not smallness but cohesion. A service should own a complete business capability. Nano-services that do one tiny thing create a distributed mess with excessive inter-service communication.

• "Microservices fix bad code" — If your monolith has tangled dependencies and poor modularity, splitting it into services just turns a tangled monolith into a tangled distributed system. Fix the architecture first.

• "You need microservices to scale" — Horizontal scaling is possible with monoliths. Most scaling bottlenecks are in the database, not the application tier. A well-optimized monolith behind a load balancer can handle enormous traffic.

• "Microservices mean you can use any language" — Technically true. Practically, supporting five different languages means five different build systems, dependency management approaches, and debugging toolchains. Most mature organizations standardize on two or three languages.

How This Appears in Interviews

Microservices architecture is a cornerstone of system design interviews:

• "Design a ride-sharing system" — decompose into services (matching, pricing, tracking, payments) and explain communication patterns. See our system design interview guide.
• "How would you break a monolith into microservices?" — discuss domain analysis, the strangler fig pattern, and how you define service boundaries using domain-driven design.
• "What happens when a downstream service is unavailable?" — discuss circuit breakers, retries with backoff, fallback strategies, and bulkhead patterns.
• Practice with our microservices interview questions.

Related Concepts

• Monolith vs Microservices — The fundamental architecture comparison
• API Gateway Pattern — How clients access microservices
• Service Mesh — Managing service-to-service communication
• Event-Driven Architecture — Async communication between services
• Domain-Driven Design — Defining service boundaries
• Strangler Fig Pattern — Migrating from monolith to microservices
• System Design Interview Guide — Comprehensive interview preparation
• Algoroq Pricing — Practice microservices design questions