Service decomposition strategies in Microservices - Scalability & System Analysis

Scalability Analysis - Service decomposition strategies

Growth Table: Service Decomposition at Different Scales

Users / Traffic	System Characteristics	Service Decomposition	Challenges
100 users	Low traffic, simple features	Monolith or few coarse-grained services	Minimal overhead, easy coordination
10,000 users	Moderate traffic, growing features	Split by business capabilities (e.g., user, order, payment)	Service boundaries start to matter, data duplication risk
1 million users	High traffic, many teams, complex domain	Fine-grained services, domain-driven design, bounded contexts	Inter-service communication overhead, data consistency
100 million users	Very high traffic, global scale	Highly autonomous services, event-driven, asynchronous flows	Network latency, eventual consistency, operational complexity

First Bottleneck

At small scale, the monolithic database or tightly coupled services become the bottleneck due to limited scalability and deployment speed.

As users grow, the main bottleneck shifts to inter-service communication overhead and data consistency challenges between services.

At very large scale, network latency and operational complexity (deployments, monitoring) become the biggest challenges.

Scaling Solutions for Service Decomposition

• Horizontal scaling: Run multiple instances of services behind load balancers to handle more requests.
• Service boundaries: Decompose by business capabilities or domain to reduce coupling and improve team autonomy.
• Data management: Use database per service pattern, with asynchronous events for data sync to reduce tight coupling.
• Communication: Prefer asynchronous messaging (event buses, queues) over synchronous calls to reduce latency and failures.
• API gateways: Centralize access and routing to services, enabling easier client interaction and security.
• Monitoring and automation: Use centralized logging, tracing, and automated deployments to manage complexity.

Back-of-Envelope Cost Analysis

Assuming 1 million users with 1 request per second each:

• Requests per second: ~1,000,000 QPS total
• Each service instance handles ~5,000 QPS → need ~200 instances distributed across services
• Database load: split per service, each DB handles ~5,000 QPS; requires read replicas and sharding
• Network bandwidth: 1 Gbps = 125 MB/s; high traffic requires multiple network links and CDN for static content
• Storage: depends on data retention; event logs and databases require scalable storage solutions

Interview Tip: Structuring Scalability Discussion

Start by describing the current scale and system design.

Identify the first bottleneck as traffic grows.

Explain how service decomposition helps isolate and scale parts independently.

Discuss trade-offs between fine-grained and coarse-grained services.

Describe concrete scaling techniques: horizontal scaling, asynchronous communication, data partitioning.

Conclude with operational considerations like monitoring and automation.

Self Check Question

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Introduce read replicas to distribute read load and reduce pressure on the primary database. Also consider caching frequently accessed data to reduce database queries.

Key Result

Service decomposition evolves from monolith to fine-grained microservices as users grow, with the first bottleneck shifting from database limits to inter-service communication and operational complexity.

Practice

1. Which of the following best describes the main goal of service decomposition in microservices?

easy

A. Combining multiple services into one large service

B. Creating a single database for all services

C. Removing all dependencies between services

D. Breaking a large system into smaller, manageable services

Solution

1. Step 1: Understand the purpose of decomposition

   Service decomposition aims to split a big system into smaller parts for easier management.

2. Step 2: Evaluate options against this goal

   Only Breaking a large system into smaller, manageable services describes breaking down a system into smaller services, which matches the goal.

3. Final Answer:

   Breaking a large system into smaller, manageable services -> Option D

4. Quick Check:

   Service decomposition = smaller services [OK]

Hint: Decomposition means splitting big into small [OK]

Common Mistakes:

• Thinking decomposition means merging services
• Assuming it removes all dependencies
• Confusing decomposition with database design

2. Which of the following is a common strategy to decompose microservices?

easy

A. By server hardware

B. By business capability

C. By programming language

D. By network protocol

Solution

1. Step 1: Recall common decomposition strategies

   Common strategies include decomposing by business capability, subdomain, or data entity.

2. Step 2: Match options to known strategies

   Only By business capability matches a recognized strategy; others are unrelated to service design.

3. Final Answer:

   By business capability -> Option B

4. Quick Check:

   Decompose by business function = C [OK]

Hint: Decompose by what the business does [OK]

Common Mistakes:

• Choosing technical infrastructure as decomposition criteria
• Confusing programming language with service boundaries
• Thinking network protocols define services

3. Given a system with services decomposed by subdomain, which of the following is a likely benefit?

medium

A. Single point of failure for all features

B. Reduced number of services to manage

C. Improved team autonomy and focused development

D. Elimination of all data duplication

Solution

1. Step 1: Understand subdomain decomposition

   Decomposing by subdomain groups services by business areas, enabling teams to work independently.

2. Step 2: Analyze benefits

   This approach improves team autonomy and focus, but does not reduce services or eliminate data duplication fully.

3. Final Answer:

   Improved team autonomy and focused development -> Option C

4. Quick Check:

   Subdomain decomposition = team autonomy [OK]

Hint: Subdomain splits by business area, helps teams [OK]

Common Mistakes:

• Assuming fewer services means better decomposition
• Expecting zero data duplication always
• Thinking it creates single failure points

4. A team decomposed services by data entity but faces tight coupling between services. What is the likely cause?

medium

A. Services share too much data and depend on each other

B. Services are deployed on different servers

C. Services use different programming languages

D. Services have separate databases

Solution

1. Step 1: Identify cause of tight coupling

   Tight coupling often happens when services share data heavily and depend on each other.

2. Step 2: Evaluate options

   Only Services share too much data and depend on each other explains tight coupling due to shared data and dependencies; others are unrelated.

3. Final Answer:

   Services share too much data and depend on each other -> Option A

4. Quick Check:

   Tight coupling = shared data dependency [OK]

Hint: Tight coupling means services depend on shared data [OK]

Common Mistakes:

• Blaming deployment location for coupling
• Thinking different languages cause tight coupling
• Assuming separate databases cause coupling

5. You are designing a microservices system for an online store. Which decomposition strategy best supports independent team ownership and scalability?

hard

A. Decompose by business capability like order management, payment, and inventory

B. Decompose by database tables to minimize data duplication

C. Decompose by programming language to use best tools per service

D. Decompose by server location to reduce network latency

Solution

1. Step 1: Identify goals for decomposition

   Independent team ownership and scalability require clear service boundaries aligned with business functions.

2. Step 2: Match strategies to goals

   Decomposing by business capability groups related functions, enabling teams to own services and scale independently.

3. Step 3: Evaluate other options

   Decomposing by tables or languages does not align with team ownership; server location affects latency, not ownership.

4. Final Answer:

   Decompose by business capability like order management, payment, and inventory -> Option A

5. Quick Check:

   Business capability decomposition = team ownership + scalability [OK]

Hint: Group by business functions for team and scale benefits [OK]

Common Mistakes:

• Choosing database tables over business functions
• Thinking programming language defines service boundaries
• Focusing on server location instead of service design