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.