Identifying service boundaries in Microservices - Deep Dive

Overview - Identifying service boundaries

What is it?

Identifying service boundaries means deciding how to split a big software system into smaller, independent parts called services. Each service handles a specific job or business area. This helps teams work separately and makes the system easier to manage and grow. It is a key step in designing microservices architecture.

Why it matters

Without clear service boundaries, software becomes tangled and hard to change. Teams get stuck waiting on each other, and bugs spread easily. Good boundaries let teams build, test, and fix parts without breaking others. This speeds up development and keeps users happy with reliable features.

Where it fits

Before this, you should understand basic software design and what microservices are. After learning service boundaries, you can explore communication between services, data management, and deployment strategies. It fits early in the microservices design journey.

Mental Model

Core Idea

Service boundaries are like invisible fences that separate a big system into smaller, focused parts that can work independently but cooperate when needed.

Think of it like...

Imagine a city divided into neighborhoods. Each neighborhood has its own shops, parks, and homes. People live and work mostly inside their neighborhood but visit others when necessary. This keeps the city organized and easy to manage.

┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│   Service A   │   │   Service B   │   │   Service C   │
│ (User Login)  │   │ (Orders)      │   │ (Payments)    │
└──────┬────────┘   └──────┬────────┘   └──────┬────────┘
       │                   │                   │
       └───────┬───────────┴───────────┬───────┘
               │                       │
         Shared Data or API Gateway

Build-Up - 7 Steps

1

Foundation

Understanding monolithic systems

Concept: Learn what a monolithic system is and why it can be hard to maintain.

A monolithic system is one big program where all parts are tightly connected. For example, user login, product catalog, and payment processing are all inside one codebase. Changes in one part can affect others, making updates risky and slow.

Result

You see why breaking a system into smaller parts can help manage complexity.

Understanding the limits of monoliths shows why we need to find good service boundaries.

2

Foundation

What is a microservice?

Concept: Introduce the idea of microservices as small, focused services.

Microservices are independent programs that do one job well. For example, one service handles user accounts, another handles orders. They communicate over networks but run separately. This allows teams to develop and deploy services independently.

Result

You grasp the basic building blocks that service boundaries create.

Knowing what microservices are helps you see why splitting a system matters.

3

Intermediate

Domain-driven design basics

🤔Before reading on: do you think service boundaries should be based on technical layers or business areas? Commit to your answer.

Concept: Learn how business domains guide service boundaries using domain-driven design (DDD).

DDD suggests dividing software by business areas called domains. For example, 'User Management' and 'Order Processing' are separate domains. Each domain becomes a service boundary because it groups related functions and data.

Result

You understand that business meaning, not just code structure, drives boundaries.

Understanding that boundaries reflect business domains prevents creating arbitrary or technical-only splits.

4

Intermediate

Identifying bounded contexts

🤔Before reading on: do you think one service should handle multiple business domains or just one? Commit to your answer.

Concept: Bounded contexts are clear boundaries around a domain where terms and rules have specific meanings.

Within a domain, a bounded context defines where a model applies consistently. For example, 'Payment' means one thing in billing and another in fraud detection. Each bounded context can become a service boundary to avoid confusion and conflicts.

Result

You learn to spot natural boundaries inside complex domains.

Knowing bounded contexts helps avoid mixing responsibilities that cause bugs and slow development.

5

Intermediate

Using data ownership to split services

Concept: Learn how data ownership guides service boundaries to reduce conflicts.

Each service should own its data and not share databases with others. For example, the 'Orders' service owns order data, and the 'Users' service owns user profiles. This prevents accidental data corruption and allows independent scaling.

Result

You see why data boundaries matter for service independence.

Understanding data ownership avoids tight coupling and complex coordination between services.

6

Advanced

Handling cross-service communication

🤔Before reading on: do you think services should call each other directly or use messaging? Commit to your answer.

Concept: Explore how services interact and how boundaries affect communication patterns.

Services communicate via APIs or messaging. Tight boundaries mean fewer calls between services, reducing delays and failures. Designing boundaries to minimize cross-service calls improves performance and reliability.

Result

You appreciate how boundaries impact system speed and fault tolerance.

Knowing communication costs guides better boundary decisions to keep services loosely coupled.

7

Expert

Recognizing anti-patterns in boundaries

🤔Before reading on: do you think splitting services too small is always better? Commit to your answer.

Concept: Identify common mistakes like creating too many tiny services or overlapping responsibilities.

Too many small services cause overhead in communication and deployment. Overlapping boundaries cause confusion and bugs. Experts balance granularity to keep services manageable and cohesive.

Result

You learn to avoid pitfalls that degrade system quality.

Understanding anti-patterns helps maintain a healthy balance between independence and complexity.

Under the Hood

Service boundaries define where code, data, and responsibilities stop and start. Internally, each service runs in its own process or container with its own database. They communicate over networks using APIs or messaging. This separation isolates failures and allows independent updates.

Why designed this way?

Originally, software was built as monoliths for simplicity. As systems grew, monoliths became hard to maintain. Microservices emerged to improve scalability and team autonomy. Boundaries were designed to reflect business domains to keep services meaningful and manageable.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Service A   │──────▶│   Service B   │──────▶│   Service C   │
│ (Owns Data A) │       │ (Owns Data B) │       │ (Owns Data C) │
└──────┬────────┘       └──────┬────────┘       └──────┬────────┘
       │                       │                       │
       ▼                       ▼                       ▼
  Database A              Database B              Database C

Myth Busters - 4 Common Misconceptions

Quick: Do you think one microservice should share a database with another? Commit yes or no.

Common Belief: Many believe services can share the same database to simplify data access.

Reality: Each service should have its own database to maintain independence and avoid tight coupling.

Why it matters: Sharing databases causes hidden dependencies and makes independent deployment and scaling impossible.

Quick: Is it better to have many tiny services or fewer larger ones? Commit your answer.

Common Belief: Some think splitting into very small services is always better for flexibility.

Reality: Too many tiny services increase communication overhead and complexity, hurting performance and maintainability.

Why it matters: Over-splitting leads to fragile systems with high operational costs.

Quick: Should service boundaries be based mainly on technical layers like UI or database? Commit yes or no.

Common Belief: People often believe splitting by technical layers is the best way to define services.

Reality: Boundaries should be based on business domains and responsibilities, not technical layers.

Why it matters: Technical-layer splits cause services to be tightly coupled and hard to evolve independently.

Quick: Do you think services must never communicate directly? Commit yes or no.

Common Belief: Some think services should be completely isolated with no direct communication.

Reality: Services need to communicate but should do so through well-defined APIs or messaging to keep boundaries clear.

Why it matters: No communication means no collaboration; uncontrolled communication breaks boundaries.

Expert Zone

1

Service boundaries often evolve over time as business needs change; rigid initial boundaries can cause technical debt.

2

Sometimes a service boundary must balance between data consistency and availability, requiring careful trade-offs.

3

Cross-cutting concerns like logging or authentication should be handled outside core service boundaries to avoid mixing responsibilities.

When NOT to use

Microservice boundaries are not ideal for very small or simple applications where overhead outweighs benefits. In such cases, a modular monolith or layered architecture is better.

Production Patterns

In real systems, teams use domain-driven design to define boundaries, implement API gateways for routing, and use event-driven communication to decouple services. Boundaries align with team ownership to enable parallel development.

Connections

Domain-Driven Design

Builds-on

Understanding domain-driven design helps identify meaningful service boundaries that reflect real business concepts.

Database Normalization

Similar pattern

Both service boundaries and normalization aim to reduce duplication and improve data integrity by organizing data logically.

Urban Planning

Analogous concept from a different field

Just like city planners divide a city into neighborhoods to manage growth and services, software architects divide systems into services to manage complexity and scale.

Common Pitfalls

#1 Creating services that share the same database schema.

Wrong approach:

Service A and Service B both read and write to the same 'users' table in a shared database.

Correct approach:

Service A owns the 'users' table and exposes APIs; Service B calls Service A's API instead of accessing the database directly.

Root cause:

Misunderstanding that database sharing breaks service independence and coupling boundaries.

#2 Splitting services too finely without clear boundaries.

Wrong approach:

Creating separate services for 'user login', 'user profile', and 'user preferences' without strong domain separation.

Correct approach:

Combine related user functions into a single 'User Management' service with clear responsibilities.

Root cause:

Belief that smaller services are always better, ignoring communication overhead and complexity.

#3 Defining service boundaries based on technical layers like UI or database access.

Wrong approach:

One service handles all UI logic, another handles all database access for all domains.

Correct approach:

Define services around business domains like 'Orders' or 'Payments' that include UI, logic, and data for that domain.

Root cause:

Confusing technical separation with business responsibility separation.

Key Takeaways

Service boundaries split a large system into smaller, focused parts that reflect business domains.

Good boundaries reduce dependencies, allowing teams to work independently and systems to scale.

Boundaries should be based on business meaning, data ownership, and clear responsibilities, not just technical layers.

Avoid sharing databases between services to maintain independence and prevent tight coupling.

Over-splitting services or unclear boundaries increase complexity and operational overhead.

Practice

1. Which of the following best describes the primary goal when identifying service boundaries in microservices?

easy

A. Create services based on the number of developers available

B. Split services evenly by code size

C. Group all database operations into one service

D. Divide the system based on business capabilities and data ownership

Solution

1. Step 1: Understand the purpose of service boundaries

   Service boundaries should reflect business capabilities to ensure clear ownership and independent deployment.

2. Step 2: Evaluate the options

   Options B, C, and D focus on technical or team size factors, which are less effective than business-driven boundaries.

3. Final Answer:

   Divide the system based on business capabilities and data ownership -> Option D

4. Quick Check:

   Business capabilities = A [OK]

Hint: Match services to business functions, not code size or teams [OK]

Common Mistakes:

• Splitting services by code size only
• Grouping all database logic in one service
• Ignoring business domain boundaries

2. Which of the following is the correct way to define a microservice boundary?

easy

A. A service that handles user authentication and profile management

B. A service that mixes payment processing and product catalog updates

C. A service that only manages database connections

D. A service that handles logging for all other services

Solution

1. Step 1: Identify cohesive responsibilities

   A good service boundary groups related business functions, like authentication and profile management.

2. Step 2: Check for unrelated responsibilities

   Options A, B, and C mix unrelated concerns or are cross-cutting, which should be separate services or infrastructure.

3. Final Answer:

   A service that handles user authentication and profile management -> Option A

4. Quick Check:

   Cohesive business functions = D [OK]

Hint: Group related business tasks in one service [OK]

Common Mistakes:

• Combining unrelated business functions
• Creating services for technical concerns only
• Mixing cross-cutting concerns inside business services

3. Given a system with services: OrderService managing orders, InventoryService managing stock, and PaymentService handling payments, which service boundary violation is shown if OrderService directly updates stock quantities?

medium

A. OrderService is violating the single responsibility principle by managing inventory data

B. OrderService is correctly handling all order-related data including stock

C. PaymentService should update stock quantities instead

D. InventoryService should not exist separately from OrderService

Solution

1. Step 1: Analyze service responsibilities

   OrderService should focus on orders; InventoryService owns stock data and updates.

2. Step 2: Identify boundary violation

   OrderService updating stock breaks clear ownership and single responsibility principles.

3. Final Answer:

   OrderService is violating the single responsibility principle by managing inventory data -> Option A

4. Quick Check:

   Single responsibility violation = B [OK]

Hint: Each service owns its data; no direct updates outside boundaries [OK]

Common Mistakes:

• Allowing services to update data owned by others
• Confusing payment service role
• Merging unrelated services unnecessarily

4. A team notices that their UserService and NotificationService are tightly coupled because UserService calls NotificationService directly for every user update. What is the best way to fix this boundary issue?

medium

A. Make NotificationService call UserService instead

B. Merge both services into one to avoid communication

C. Use an event-driven approach where UserService emits events and NotificationService listens

D. Remove NotificationService and handle notifications inside UserService

Solution

1. Step 1: Understand tight coupling problem

   Direct calls create dependencies that reduce service independence.

2. Step 2: Apply event-driven design

   Emitting events decouples services, allowing independent scaling and deployment.

3. Final Answer:

   Use an event-driven approach where UserService emits events and NotificationService listens -> Option C

4. Quick Check:

   Event-driven decoupling = C [OK]

Hint: Use events to decouple services, not direct calls [OK]

Common Mistakes:

• Merging services unnecessarily
• Reversing call direction without decoupling
• Ignoring decoupling benefits

5. You are designing a microservices system for an e-commerce platform. Which approach best defines service boundaries to maximize team autonomy and scalability?

hard

A. Create services based on technical layers like UI, Business Logic, and Database Access

B. Define services around distinct business domains like Catalog, Orders, Payments, and Shipping, each owning its data and APIs

C. Split services by database tables regardless of business function

D. Group all user-related features into one large service to reduce communication

Solution

1. Step 1: Identify business domain boundaries

   Services aligned with business domains allow clear ownership and independent scaling.

2. Step 2: Avoid technical or data-layer splits

   Splitting by technical layers or tables causes tight coupling and reduces autonomy.

3. Step 3: Consider team autonomy and scalability

   Domain-based services enable teams to work independently and scale services as needed.

4. Final Answer:

   Define services around distinct business domains like Catalog, Orders, Payments, and Shipping, each owning its data and APIs -> Option B

5. Quick Check:

   Domain-driven design = A [OK]

Hint: Align services with business domains for autonomy and scale [OK]

Common Mistakes:

• Splitting by technical layers instead of business domains
• Grouping unrelated features together
• Ignoring data ownership in service design