How Many Microservices

Interview classic: “I have a monolith. Into how many microservices should I divide it?”

There isn’t a number. It depends on the use case, the size of the monolith, and what operations actually matter. Different engineers will also cut the same system differently — by technology, by database, by read vs write. That’s normal.

What you can say is a method.

Use domain-driven design to get to a number

In domain-driven design, you divide the monolith domain-wise. Domains can split further into subdomains. How far you go depends on size and operations.

Example: payments. Inside payments you might have refunds, forwarding, tracking. If that slice of the product is big enough, a particular operation may deserve its own service. Or it may not. Requirements decide — not a checklist.

In an interview, the safe, concrete answer is: I’ll use a domain-driven approach to figure out how many services we need, then walk the interviewer through the phases.

Monolith

Now at: Monolith → next Domains

The count falls out of the domain — not a target number picked up front.

Monolith
   │
   ▼
Domains ──► Subdomains ──► Bounded contexts ──► Services
              │
         (size & ops decide
          how far you split)

Phase 1 — understand the domain

Without domain understanding, you can’t divide at the domain level.

Sit with domain experts — they hold the requirements and the real vocabulary. Talk through the problem you’re solving. Include end users when you can. You’re trying to get a concrete division, not a guess from the org chart.

Phase 2 — come up with subdomains

Each subdomain is a candidate to become a microservice. So be careful and concrete.

Possible domains for a simple app (or e-commerce) aren’t fixed until you’ve done that conversation. One practical way teams discover them in DDD is event storming — a whiteboard session that surfaces events, sequences, and then bounded contexts.

What you still won’t get

Even with DDD, you don’t get a universal fixed number. Engineer judgment and use case still matter. Some people will push a technology cut. Some will push read/write services. DDD is the interview-friendly spine because it ties the cut to the business, not to fashion.

When not to use this

Don’t invent twelve domains for a CRUD app with one team and one database. DDD is a lens for complexity — if the complexity isn’t there yet, a modular monolith (or fewer services) is the honest answer.

Also don’t treat “DDD” as a synonym for “microservices.” You can use domains and bounded contexts inside one deployable.

Production pitfall

Counting services before understanding the domain. Teams pick “we’ll have eight services” because eight sounds reasonable, then force the business into those boxes. Start from experts and events; let the count fall out of the boundaries.