Microservices

Amazon Prime Video moved part of their video monitoring system back to a monolith in 2023 to reduce latency and operational complexity. Segment did the same with their event pipeline. Even Istio — the tool literally designed for managing microservices — consolidated several control-plane services to reduce operational burden.

These weren’t failures of microservices. They were signs of engineering maturity. After a decade of adoption, the industry has learned when microservices make sense and when they don’t.

Anatomy of a Microservice

A microservice is a small, autonomous service that does one thing well. “Small” is about scope, not lines of code. The defining characteristics:

The Benefits

Independent scaling lets you allocate resources where you need them — scale video processing during peak hours while keeping baseline capacity for user profiles.

Team autonomy lets organizations move faster by reducing coordination cost and letting teams pick their own stacks and deployment cadence.

Fault isolation means a failure in one service doesn’t necessarily take down the whole system. The recommendation engine can struggle while users still browse, search, and check out.

The Real Costs

The complexity is what teams routinely underestimate.

The common pain points:

• Operational overhead. Instead of monitoring one app, you’re monitoring 50 — each with its own logs, metrics, and pipeline.
• Service sprawl. Following “do one thing well” too literally produces services so granular that simple business operations require complex coordination.
• Cognitive load. Tracking dependencies, understanding data flows, coordinating deploys across a service mesh can paralyze velocity.
• Data consistency. When a customer places an order, you might need to update inventory, process payment, and send notifications across multiple services — handling failures correctly is non-trivial.

Anti-patterns to Avoid

Communication: The Nervous System

In a monolith, method calls are cheap and reliable. In microservices, communication becomes a primary design concern. How services talk to each other determines latency, reliability, and failure modes.

Most production systems mix patterns. We covered communication patterns in detail in the previous section.

Boundary Problem

The single most consequential decision in microservices architecture is where to put the boundaries. Get it right and you unlock fast independent teams. Get it wrong and you’ve built a distributed big ball of mud that’s harder to manage than the monolith you started with.

DDD as your guide

DDD’s bounded contexts map naturally onto service boundaries. A bounded context is a business area where specific terms, rules, and models apply consistently — exactly the right unit of decomposition.

In an e-commerce system, “Customer” means different things in different contexts:

• Sales: purchase history, preferences, loyalty status.
• Support: tickets, issue history, satisfaction ratings.
• Billing: payment methods, invoices, credit limits.

Each becomes its own service with its own data model.

Practical heuristics

Migrating: The Strangler Fig

Most organizations don’t start with microservices — they evolve toward them. The Strangler Fig pattern (named for the vine that gradually overtakes its host tree) is the systematic approach:

This reduces risk and lets you adjust as you go. Read-only services (search, recommendations) make easier first targets than transactional ones.

The Tech Stack That Made This Practical

Testing Distributed Systems

Microservices break the classic test pyramid in interesting ways.

The other shift: testing in production stops being a slogan and becomes necessary. Synthetic monitoring, canary deploys, and feature flags let you validate behavior under real conditions. The philosophy is optimizing MTTR over MTBF — accept that some failures will happen and design for fast recovery.

The Pendulum Swings Back

After a decade, the most thoughtful teams have moved past the binary “monolith vs. microservices” question:

The best teams have stopped arguing monolith vs. microservices and build systems that mix patterns based on what each part of the product needs. Payment processing might be tightly integrated for predictable performance. Recommendations might be loosely coupled microservices for experimental flexibility. That’s not a compromise — that’s engineering judgment.

Recap

• Microservices = small, autonomous, business-capability-aligned services with independent data ownership and deployment.
• Real benefits at scale; real costs in complexity. Underestimating the costs is the most common mistake.
• The boundary problem is the single most consequential decision; DDD bounded contexts are the best guide.
• Strangler Fig is the safe migration path from monolith to services.
• Modern tooling (K8s, service mesh, observability) made microservices practical — but didn’t make them universally appropriate.
• The mature view is adaptive architecture: pick the right pattern for each part of the system, not for the whole.