We adopted microservices because Netflix did. We were four developers building a CRUD product that had, at launch, about 50 daily active users. We were not Netflix.

Why we actually chose them

Every reason on our list was a social reason, not an architectural one: "it's the modern way," the conference talks made it look inevitable, and it looked good on our CVs. The questions that should have driven the decision — do parts of the system have independent scaling needs, do we have multiple teams that need to ship independently, is the domain complex enough to justify hard boundaries — were never asked. The honest answers would have been no, no, and no: 200 orders a day, one team, simple CRUD.

What we built

  • Eight services: API gateway, auth, user, product, order, notification, analytics, admin
  • Kafka, Redis, and Elasticsearch to wire them together, plus PostgreSQL
  • Twelve CI/CD pipelines, one per deployable
  • Infrastructure bill: about $3,000/month

A boring Django or Rails monolith on PostgreSQL — running on a $20/month droplet — would have handled that workload without noticing, and shipped in two weeks instead of six months. Instead we had network calls where function calls would have done, and distributed transactions we could not fully reason about.

The team math

Four developers and twelve deployables means each person "owns" three services, and the bus factor of every service is one. When the developer who owned auth went on vacation, an auth bug sat for two days because nobody else knew the code. On-call for everything meant permanently on-call. A single feature routinely touched three services and needed coordinated deploys, so "can you look at my service?" became a daily ritual and the context-switching never stopped.

There is no established per-service headcount rule, and we won't invent one. The actual industry guidance is about cognitive load: a single team should own a set of services small enough to genuinely understand, operate, and be on call for. By that standard, a four-person team owns one system — maybe two — not twelve.

What we should have done

Start with a well-structured monolith with enforced module boundaries, and extract a service only when a specific, measured pressure demands it — a component that scales differently, or a team that needs to deploy independently. Our guide to when microservices architecture actually pays off covers those triggers, and consolidating an estate like this back down is its own delicate project — one we treat as a first-class DevOps engagement rather than a weekend refactor.

Lesson: Microservices are an organizational scaling strategy, not a technical upgrade. They solve coordination problems between many teams; if you don't have those problems, they will manufacture new ones. If your whole team fits in one meeting room, you almost certainly don't need them.

← Back to Lessons Learned
Tags: #Microservices #Architecture #TeamSize #Antipattern