Originally published on lavkesh.com

Every growing engineering team eventually hits a wall with their monolith. Deployments slow down, teams step on each other, scaling one feature means scaling everything. Microservices promise to fix that. But the tradeoffs are real, and most teams underestimate the cost side of the equation.

Microservices architecture means building an application as a collection of small, independent services that communicate through APIs. Each service owns one business capability and can be developed, deployed, and scaled completely independently. This is the opposite of monolithic architecture, where every part of the application is tightly coupled.

With microservices, scaling becomes granular. In a monolith, a payment processing bottleneck means you double your entire application's infrastructure. With microservices, you scale just the payment service. This saves money and means you can handle traffic spikes without over-provisioning everything.

Each team can pick their tools. The user service can use Python, the search service can use Go, and the inventory service can use Java. Teams use what makes sense for their problem instead of being locked into a company-wide technology stack.

Failure stays isolated with microservices. A memory leak in the payment service doesn't bring down your API gateway or user service. Users see a degraded payment service, not a completely broken application. This resilience is crucial when you're running software that thousands or millions of people depend on.

Deployment gets faster with microservices. Different teams deploy independently. Your team ships a feature on Tuesday morning, and the platform team deploys a configuration change on Wednesday afternoon. No coordinated release windows, no waiting for other teams.

In practice the speed you get from independent deployments only shows up if your CI/CD plumbing can keep up. At my last company we ran 120 pipelines on GitLab CI, each pushing a Docker image to ECR and then triggering an ArgoCD sync. The first time we tried to ship a hotfix at 2 am the runner pool was exhausted, the pipeline stalled for 45 minutes and the payment service stayed down longer than the outage itself. We ended up consolidating pipelines around a shared base image and throttling the number of concurrent builds. The lesson was that the automation layer becomes a single point of failure if you don't size it for peak parallelism.

Code changes become manageable. A monolith with 50 engineers becomes a nightmare of merge conflicts and dependencies. Microservices let 50 engineers work on 50 different services without stepping on each other's toes.

Data consistency is the hidden cost that catches most teams off guard. We moved an order‑fulfillment flow to three services - order, inventory, and billing - and relied on eventual consistency via Kafka topics. When a duplicate inventory event slipped through, the billing service charged the customer twice. We introduced a Saga orchestrator using Temporal and made every step idempotent, which added about 15 % latency but saved us from costly refunds. The trade‑off is clear: you pay in latency and code complexity to avoid distributed transaction nightmares.

The cost of microservices is real. They solve deployment and scalability problems but create distributed systems problems. Your data is split across services, consistency gets complicated, and transactions don't work the way they do in monoliths.

Microservices aren't free. They're a bet that you'll pay for operating complexity now to scale to the size you're aiming for. If you're three engineers building a side project, microservices are overkill. If you're a company with hundreds of engineers, they're probably necessary.

Observability exploded once we hit ten services. We instrumented each with Prometheus exporters and shipped traces to Jaeger. The cardinality of label combinations on request latency metrics grew to over 200 k, blowing up storage costs on our hosted Prometheus cluster. We trimmed the label set, rolled up high‑cardinality dimensions into separate logs, and switched to Loki for log aggregation. The net effect was a 40 % reduction in monitoring spend, but it required a disciplined naming convention and regular hygiene runs.

Start monolithic if you're not sure. Monoliths work great and are way simpler. When you actually feel the pain of monolithic deployment coordination or monolithic scaling limits, that's when microservices start making sense.

If you do go microservices, start small. Maybe three services, not thirty. Give yourself time to learn how to operate microservices before you have too many. The operational complexity is real and it sneaks up on you.

Microservices work when you have organizational alignment: teams own services, deployment is automated, operations is solid. Without those, you just get distributed monoliths with extra complexity.