High cohesion in Microservices - System Design Guide

Problem Statement

When a microservice handles many unrelated responsibilities, it becomes hard to maintain and update. Changes in one part can cause unexpected issues in others, slowing down development and increasing bugs.

Solution

High cohesion means designing each microservice to focus on a single, well-defined responsibility. This keeps the service simple, easier to understand, and reduces dependencies between parts, making updates safer and faster.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  User Service │──────▶│  Order Service│──────▶│ Payment Service│
│ (User logic)  │       │ (Order logic) │       │ (Payment logic)│
└───────────────┘       └───────────────┘       └───────────────┘

This diagram shows three microservices each focused on a single responsibility: user management, order processing, and payment handling, illustrating high cohesion.

Trade-offs

✓ Pros

→

Improves maintainability by isolating changes to one service.

→

Enables independent deployment and scaling of services.

→

Reduces risk of bugs spreading across unrelated features.

→

Simplifies understanding and testing of each service.

✗ Cons

→

May increase the number of services to manage and monitor.

→

Requires careful API design to handle inter-service communication.

→

Can introduce latency due to network calls between services.

Use high cohesion when building microservices that need to be independently deployable and scalable, especially when the system has multiple distinct business capabilities.

Avoid strict high cohesion in very small systems or prototypes where overhead of multiple services outweighs benefits, typically under 1000 daily users.

Real World Examples

Amazon

Amazon splits its platform into microservices like product catalog, order management, and payment to allow teams to work independently and deploy changes without affecting others.

Netflix

Netflix uses high cohesion by separating services such as user profiles, streaming, and recommendations, enabling rapid innovation and fault isolation.

Uber

Uber divides its system into services like ride matching, payments, and notifications, each focused on a single responsibility to scale and evolve independently.

Code Example

The before code shows one service mixing user and order logic, making it harder to maintain. The after code splits responsibilities into two focused classes, improving cohesion and maintainability.

Microservices

### Before: Low cohesion microservice handling users and orders
class Service:
    def create_user(self, user_data):
        # user creation logic
        pass

    def create_order(self, order_data):
        # order creation logic
        pass

### After: High cohesion with separate services
class UserService:
    def create_user(self, user_data):
        # user creation logic
        pass

class OrderService:
    def create_order(self, order_data):
        # order creation logic
        pass

Alternatives

Low cohesion (monolithic service)

Combines many unrelated responsibilities into one service, increasing coupling and complexity.

Use when: Choose when the system is small, simple, or early in development to reduce operational overhead.

Modular monolith

Keeps high cohesion within modules but deploys as a single application, reducing network overhead.

Use when: Choose when you want clear boundaries but prefer simpler deployment and lower latency.

Summary

High cohesion means designing microservices to focus on a single responsibility.

It improves maintainability, scalability, and reduces bugs by isolating changes.

It is best used in systems with multiple distinct business capabilities requiring independent deployment.

Practice

1. What does high cohesion mean in microservices architecture?

easy

A. Using a single database for all microservices

B. Splitting every function into separate services regardless of relation

C. Combining unrelated tasks to reduce the number of services

D. Grouping related tasks and responsibilities within a single service

Solution

1. Step 1: Understand the meaning of cohesion

   Cohesion means how closely related the tasks inside a module or service are.

2. Step 2: Apply cohesion to microservices

   High cohesion means grouping related tasks in one service to keep it focused and manageable.

3. Final Answer:

   Grouping related tasks and responsibilities within a single service -> Option D

4. Quick Check:

   High cohesion = grouping related tasks [OK]

Hint: High cohesion means related tasks stay together [OK]

Common Mistakes:

• Thinking high cohesion means splitting every function separately
• Confusing cohesion with coupling
• Believing unrelated tasks should be combined
• Assuming database design defines cohesion

2. Which of the following is the correct way to describe a microservice with high cohesion?

easy

A. A service that manages all user-related operations like profile, login, and preferences

B. A service that mixes order processing and inventory updates randomly

C. A service that handles user authentication and payment processing

D. A service that only stores data without any business logic

Solution

1. Step 1: Identify related tasks in options

   A service that manages all user-related operations like profile, login, and preferences groups user-related operations which are closely related.

2. Step 2: Check other options for unrelated tasks

   Options A and B mix unrelated tasks; D lacks business logic, so not cohesive.

3. Final Answer:

   A service that manages all user-related operations like profile, login, and preferences -> Option A

4. Quick Check:

   High cohesion = related user tasks together [OK]

Hint: Look for grouping of related tasks in one service [OK]

Common Mistakes:

• Choosing options that mix unrelated responsibilities
• Ignoring business logic in cohesion
• Confusing data storage with service responsibility
• Assuming more tasks always mean better cohesion

3. Consider a microservice design where the OrderService handles order creation, payment processing, and shipping updates. What is the likely issue with this design regarding high cohesion?

medium

A. The service has low cohesion because it mixes unrelated responsibilities

B. The service has high cohesion because all tasks relate to orders

C. The service is scalable because it handles multiple tasks

D. The service is loosely coupled with other services

Solution

1. Step 1: Analyze the tasks in OrderService

   Order creation, payment, and shipping are different domains with distinct logic.

2. Step 2: Evaluate cohesion

   Mixing payment and shipping with order creation lowers cohesion because responsibilities differ.

3. Final Answer:

   The service has low cohesion because it mixes unrelated responsibilities -> Option A

4. Quick Check:

   Mixed tasks = low cohesion [OK]

Hint: Different domains in one service reduce cohesion [OK]

Common Mistakes:

• Assuming all order-related tasks are always cohesive
• Confusing scalability with cohesion
• Ignoring domain boundaries
• Believing loosely coupled means high cohesion

4. A microservice named InventoryService currently manages stock levels and supplier payments. What is the best fix to improve high cohesion?

medium

A. Combine InventoryService with OrderService

B. Add customer order tracking to InventoryService

C. Split supplier payments into a separate PaymentService

D. Keep all tasks in InventoryService for simplicity

Solution

1. Step 1: Identify unrelated responsibilities

   Supplier payments are unrelated to stock level management.

2. Step 2: Suggest separation for high cohesion

   Moving payments to a dedicated PaymentService improves cohesion by grouping related tasks.

3. Final Answer:

   Split supplier payments into a separate PaymentService -> Option C

4. Quick Check:

   Separate unrelated tasks to improve cohesion [OK]

Hint: Separate unrelated tasks into different services [OK]

Common Mistakes:

• Adding unrelated tasks to the same service
• Combining unrelated services
• Ignoring cohesion for simplicity
• Confusing cohesion with coupling

5. You are designing a microservices system for an e-commerce platform. To ensure high cohesion, which of the following service groupings is best?

hard

A. UserService (user profiles, payments), OrderService (orders, shipping), InventoryService (stock levels, payments)

B. UserService (user profiles, authentication), OrderService (orders, payments), ShippingService (shipping updates, tracking)

C. One big service handling users, orders, payments, shipping, and inventory

D. Split every function into its own microservice regardless of relation

Solution

1. Step 1: Evaluate grouping of related tasks

   UserService (user profiles, authentication), OrderService (orders, payments), ShippingService (shipping updates, tracking) groups related tasks logically by domain, supporting high cohesion.

2. Step 2: Compare with other options

   UserService (user profiles, payments), OrderService (orders, shipping), InventoryService (stock levels, payments) mixes payments in unrelated services; C is a monolith; D over-splits causing low cohesion.

3. Final Answer:

   UserService (user profiles, authentication), OrderService (orders, payments), ShippingService (shipping updates, tracking) -> Option B

4. Quick Check:

   Group related domain tasks for high cohesion [OK]

Hint: Group by domain responsibilities for high cohesion [OK]

Common Mistakes:

• Mixing unrelated tasks in one service
• Creating too many tiny services
• Building monolithic services
• Ignoring domain boundaries