Service Boundaries: How to Decide What Becomes a Microservice

Service Boundaries: How to Decide What Becomes a Microservice

Splitting the wrong thing into a service is worse than not splitting at all. Here is how to decide your service boundaries.

Use Domain-Driven Design (DDD)

Start with the business domain, not the code. List the things the business cares about: users, connections, chat, payments. Each is a candidate for a service.

Look for Bounded Contexts

A bounded context is a part of the domain that can be reasoned about independently. Auth is a bounded context. Chat is another. They have their own data, rules, and changes.

Find Independent Change Rates

If the chat feature changes every week but the auth feature changes every quarter, they are good candidates for separation. Change rate is a strong signal.

Find Independent Scaling Needs

If chat needs 20 instances but auth needs 2, that is a signal. Services that scale together can stay together.

Find Independent Teams

If team A owns chat and team B owns auth, you have a service boundary. If everyone works on everything, splitting adds coordination overhead.

Avoid Splitting by Technical Layer

Do not split into a "data access service" and a "business logic service." That is a layered architecture, not a service boundary. It couples services tightly.

Avoid Splitting Too Small

A service that does one tiny thing adds operational overhead without payoff. Each service should be substantial enough to justify running it.

The Strangler Approach

Do not split on a whiteboard. Run the monolith and watch which features need independence. Then extract those. Let the real product teach you the boundaries.

The Takeaway

Choose service boundaries using domain-driven design, bounded contexts, independent change rates, independent scaling needs, and team structure. Avoid splitting by technical layer or splitting too small. Let the real product teach you the boundaries.