Identifying service boundaries in Microservices - Scalability & System Analysis

Scalability Analysis - Identifying service boundaries

Growth Table: Identifying Service Boundaries

Users / Scale	System Changes	Service Boundaries Impact
100 users	Monolithic or few services handle requests easily. Low latency, simple deployment.	Boundaries may be coarse or unclear. Services might be combined for simplicity.
10,000 users	Increased load stresses single services. Latency and failures start to appear. Need for clear service separation grows.	Services split by business capabilities. Clear APIs and data ownership needed. Boundaries help isolate failures.
1,000,000 users	High traffic demands horizontal scaling. Database and network become bottlenecks. Service communication overhead increases.	Fine-grained services with well-defined boundaries. Event-driven or async communication preferred. Data partitioning per service.
100,000,000 users	Massive scale requires global distribution. Latency optimization critical. Data consistency challenges.	Microservices deployed regionally. Strong boundary enforcement to reduce coupling. Use of API gateways and service meshes.

First Bottleneck: Service Boundary Challenges

At small scale, unclear or broad service boundaries cause tight coupling. This leads to:

• Difficulty scaling individual parts.
• Increased failure blast radius.
• Harder to deploy or update services independently.

As users grow, the first bottleneck is the monolithic or poorly separated services that cannot scale or isolate faults well.

Scaling Solutions for Service Boundaries

• Define clear business capabilities: Split services by distinct functions (e.g., user management, payments).
• Use domain-driven design: Identify bounded contexts to guide boundaries.
• Adopt asynchronous communication: Use messaging queues to decouple services.
• Implement API gateways: Manage service access and routing.
• Apply service mesh: Control communication, security, and observability.
• Horizontal scaling: Scale services independently based on load.
• Data ownership: Each service manages its own database to avoid tight coupling.

Back-of-Envelope Cost Analysis

• Requests per second (RPS):
  At 1M users, assuming 1 request per user per minute -> ~16,700 RPS total.
  Services must handle their share independently.
• Storage:
  Each service owns data; storage scales with user data size.
  Partitioning reduces single database load.
• Bandwidth:
  Inter-service communication adds overhead.
  Use efficient protocols (gRPC, HTTP/2) to reduce cost.
• Operational cost:
  More services mean more deployment and monitoring overhead.
  Automation and orchestration tools reduce manual effort.

Interview Tip: Structuring Scalability Discussion

Start by explaining how you identify service boundaries based on business capabilities and data ownership.

Discuss how boundaries help isolate failures and enable independent scaling.

Explain the challenges of unclear boundaries at scale and how they become bottlenecks.

Describe solutions like domain-driven design, asynchronous communication, and service meshes.

Use examples to show how scaling affects service boundaries and system complexity.

Self-Check Question

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

Answer: Identify if the database is the bottleneck due to increased load. First, introduce read replicas and caching to reduce direct database queries. Then, consider splitting data ownership by service boundaries to distribute load and enable horizontal scaling.

Key Result

Clear and well-defined service boundaries enable independent scaling and fault isolation. Poor boundaries cause bottlenecks early as traffic grows, making it critical to split services by business capabilities and data ownership.

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