How Do You Decide the Boundaries of a Microservice?

A microservice boundary defines what business functionality belongs inside one service and what should belong to another service.

Choosing the correct boundary is one of the most important decisions in Microservices Architecture.

1. What is a Microservice Boundary?

A boundary determines the responsibility and ownership of a service.

Consider an E-commerce application:

E-Commerce
    |
    ├── Customer Management
    ├── Product Catalog
    ├── Order Management
    ├── Inventory
    ├── Payment
    └── Shipping

Instead of creating one large application, these business capabilities can become services:

Customer Service
Product Service
Order Service
Inventory Service
Payment Service
Shipping Service

Each service owns a clear business capability.

2. Why Do We Need Proper Boundaries?

Poor boundaries create tightly coupled services.

For example, suppose we create:

Order Service
    ↓
Order Database

Payment Service
    ↓
Directly updates Order Database

Now Payment Service depends on the internal data structure of Order Service.

This creates tight coupling.

A better design:

Order Service
      |
      | API / Event
      ↓
Payment Service

Each service controls its own logic and data.

3. How Do We Decide the Boundary?

1. Identify Business Capabilities

Start with the business, not technical layers.

For an E-commerce system:

Business Capabilities

Product Management
Order Management
Payment Processing
Inventory Management
Shipping
Notification

These are potential service boundaries.

Bad approach

Don't create services such as:

Controller Service
Repository Service
Database Service
Validation Service

These are technical layers, not business capabilities.

2. Use Domain-Driven Design — Bounded Context

A very important concept is DDD – Bounded Context.

A Bounded Context defines an area where a particular business model and terminology have a clear meaning.

For example:

Order Context
 ├── Order
 ├── OrderItem
 └── OrderStatus

Payment Context
 ├── Payment
 ├── Transaction
 └── Refund

Inventory Context
 ├── Stock
 ├── Warehouse
 └── Reservation

These bounded contexts are often strong candidates for microservice boundaries.

Important: A bounded context is a useful design boundary, but it does not automatically have to become exactly one microservice.

3. Keep Related Data and Logic Together

Things that frequently change together should usually remain together.

For example:

Order Service

Order
OrderItem
OrderStatus
Order Validation
Order Business Rules

Creating separate services for each would normally result in excessive communication:

Order Service
   ↓
OrderItem Service
   ↓
OrderStatus Service

That is usually too fine-grained.

4. Look at Data Ownership

Ask:

Who owns this data?

Example:

Product Service
   → Products

Order Service
   → Orders
   → OrderItems

Payment Service
   → Payments
   → Refunds

Inventory Service
   → Stock
   → Reservations

Clear data ownership helps define clear service boundaries.

5. Consider Independent Changes

Ask:

Can this functionality change independently?

Suppose the company frequently changes payment providers:

Payment Service
 ├── Credit Card
 ├── UPI
 └── Payment Gateway

Payment functionality may evolve independently from Product Catalog.

That makes Payment a strong candidate for a separate service.

6. Consider Independent Deployment

A good boundary should allow the service to be deployed without constantly requiring other services to be deployed.

If every change requires:

Deploy Order
     +
Deploy Payment
     +
Deploy Inventory

the services may be too tightly coupled, or their boundaries/contracts may need redesign.

7. Consider Scaling Requirements

Different business capabilities may have different workloads.

For example:

Product Search → Very High Traffic

Order          → Medium Traffic

Payment        → Lower Traffic

Separating Product/Search functionality can allow it to scale independently.

However, scaling alone should not be the only reason for choosing a business boundary.

4. Simple Real-Time Example

Consider placing an order:

Customer
   ↓
Order Service
   |
   ├──→ Inventory Service
   |
   ├──→ Payment Service
   |
   └──→ Shipping Service

Responsibilities could be:

Order Service

Create Order
Order Items
Order Status
Order History

Inventory Service

Available Stock
Reserve Stock
Release Stock

Payment Service

Process Payment
Payment Status
Refund

Shipping Service

Shipment
Tracking
Delivery Status

Each service has a clear business responsibility and data ownership.

5. How Big Should a Microservice Be?

There is no fixed rule such as:

10 Classes   = Microservice
20 APIs      = Microservice
5 Tables     = Microservice

The word "micro" does not mean minimum lines of code.

The important question is:

Does the service represent a cohesive business capability that can evolve and operate with reasonable independence?

A service can contain many classes, endpoints and tables and still be a valid microservice.

6. Signs Your Service is Too Large

A service may be too large when it:

• Handles several unrelated business capabilities.
• Is owned by many unrelated teams.
• Has unrelated functionality changing for different reasons.
• Cannot scale important workloads independently.
• Becomes difficult to understand and maintain.

Example:

BusinessService
 ├── Products
 ├── Orders
 ├── Payments
 ├── Inventory
 ├── Shipping
 └── Notifications

This is moving toward a distributed monolith/large service rather than meaningful decomposition.

7. Signs Your Services Are Too Small

Services may be too fine-grained when:

• Every operation requires several network calls.
• Services cannot perform meaningful work independently.
• Services constantly deploy together.
• There are too many distributed transactions.
• One business operation crosses many tiny services.

For example:

Order Service
OrderItem Service
OrderStatus Service
OrderValidation Service
OrderAddress Service

These responsibilities may belong together within an Order Service.

8. Advantages of Correct Boundaries

Good boundaries provide:

• High cohesion
• Loose coupling
• Independent deployment
• Independent scaling
• Clear data ownership
• Clear team ownership
• Easier maintenance
• Better fault isolation
• Easier business evolution

9. Disadvantages / Challenges

Finding boundaries can be difficult because:

• Business domains can be complex.
• Requirements change over time.
• Services may initially be divided incorrectly.
• Data relationships may cross boundaries.
• Distributed transactions become more complicated.
• Too many services create operational overhead.

Service boundaries often evolve as the team understands the domain better.

10. Key Points

When deciding a microservice boundary, consider:

Business Capability
        ↓
Bounded Context
        ↓
Related Business Rules
        ↓
Data Ownership
        ↓
Independent Change
        ↓
Independent Deployment
        ↓
Scaling Requirements
        ↓
Team Ownership

Remember:

• Design around business capabilities, not technical layers.
• Use DDD Bounded Contexts as an important guide.
• Keep strongly related logic and data together.
• Aim for high cohesion and loose coupling.
• Each service should have clear data ownership.
• Don't create services simply based on number of tables or classes.
• Avoid services that are too large or too small.
• Services that must always change/deploy together may have an incorrect boundary.

11. Interview Questions & Answers

Q1. How do you decide microservice boundaries?

I identify business capabilities and bounded contexts, then consider data ownership, cohesion, coupling, independent change, deployment, scaling and team ownership.

Q2. What is a Bounded Context?

A Bounded Context is a DDD concept that defines a clear boundary within which a particular domain model and business terminology are consistent.

Q3. Should one database table become one microservice?

No. Microservices should normally be based on business capabilities, not individual database tables.

Q4. Should every bounded context become a microservice?

Not necessarily. A bounded context provides a logical domain boundary. Deployment boundaries should also consider operational and organizational requirements.

Q5. How do you know that microservices are too tightly coupled?

Common signs are:

• Frequent synchronous calls between services.
• Direct access to another service's database.
• Services always need to be deployed together.
• Changes in one service frequently break others.

Q6. What happens if the boundaries are wrong?

You can end up with a distributed monolith—multiple deployed services that still depend heavily on each other, giving you microservice complexity without much independence.

Interview One-Line Answer

Microservice boundaries should primarily follow business capabilities and bounded contexts, keeping related business logic and data together while maintaining high cohesion, loose coupling, clear ownership, and independent deployment.