Bounded context mapping in Microservices - Scalability & System Analysis

Scalability Analysis - Bounded context mapping

Growth Table: Bounded Context Mapping at Different Scales

Users / Scale	100 Users	10,000 Users	1,000,000 Users	100,000,000 Users
Number of Microservices	2-3 small contexts	5-10 contexts	20-50 contexts	100+ contexts
Service Communication	Simple REST calls	Increased async messaging	Event-driven, message brokers	Highly decoupled, event streaming
Data Ownership	Single DB per context	Separate DBs per context	Distributed DBs, sharding	Multi-region DBs, CQRS
Deployment	Manual or simple CI/CD	Automated CI/CD pipelines	Container orchestration (K8s)	Multi-cluster, global deployment
Monitoring & Logging	Basic logs	Centralized logging	Distributed tracing	AI-driven monitoring

First Bottleneck

At small scale, the first bottleneck is unclear boundaries between contexts causing tight coupling. As users grow, the bottleneck shifts to service communication overhead and data consistency challenges. At large scale, the database and network bandwidth for cross-context communication become bottlenecks.

Scaling Solutions

• Clear Context Boundaries: Define explicit boundaries to reduce coupling.
• API Gateways & Message Brokers: Use async messaging to decouple services.
• Database per Context: Each bounded context owns its data to avoid contention.
• Event-Driven Architecture: Use events to synchronize state across contexts.
• Sharding & CQRS: Partition data and separate read/write models for scale.
• Container Orchestration: Automate deployment and scaling with Kubernetes.
• Monitoring & Tracing: Implement distributed tracing to identify bottlenecks.

Back-of-Envelope Cost Analysis

• Requests per second (RPS): 100 users ~ 10 RPS; 1M users ~ 10,000 RPS; 100M users ~ 1,000,000 RPS.
• Storage: Each context DB grows with data; 1M users may require TBs of storage.
• Network Bandwidth: Cross-service calls increase; event streaming requires high throughput.
• Compute: More services mean more CPU and memory; container orchestration costs rise.

Interview Tip

Start by explaining what bounded contexts are and why they matter. Then discuss how scaling affects boundaries, communication, and data ownership. Finally, describe concrete solutions like async messaging and database per context. Use examples to show understanding.

Self Check Question

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

Answer: Introduce read replicas and caching to reduce load. If write load grows, consider sharding or splitting data by bounded context to distribute load.

Key Result

Bounded context mapping helps keep microservices manageable as users grow by defining clear service boundaries, but communication and data consistency become bottlenecks at large scale, solved by async messaging, database per context, and event-driven patterns.

Practice

1. What is the main purpose of bounded context mapping in microservices architecture?

easy

A. To divide a system into clear, manageable parts with defined boundaries

B. To merge all services into a single large application

C. To increase the number of database tables in a system

D. To remove communication between different teams

Solution

1. Step 1: Understand bounded context concept

   Bounded context means splitting a system into parts that have clear boundaries and responsibilities.

2. Step 2: Identify the main goal of mapping

   Mapping helps teams work independently and reduces complexity by defining these boundaries.

3. Final Answer:

   To divide a system into clear, manageable parts with defined boundaries -> Option A

4. Quick Check:

   Bounded context = clear system parts [OK]

Hint: Bounded context means clear boundaries in system parts [OK]

Common Mistakes:

• Thinking bounded context merges services
• Confusing bounded context with database design
• Assuming it removes team communication

2. Which of the following correctly represents a relationship type in bounded context mapping?

easy

A. Customer/Supplier means contexts never communicate

B. Shared Kernel means two contexts share a small part of their domain model

C. Open Host Service means one context copies all data from another context

D. Conformist means contexts ignore each other's models completely

Solution

1. Step 1: Review relationship types in bounded context mapping

   Shared Kernel means two contexts share a small, common part of their domain model to stay consistent.

2. Step 2: Check other options for correctness

   Open Host Service is about providing a stable interface, not copying all data. Customer/Supplier implies communication. Conformist means one context adapts to another's model, not ignoring it.

3. Final Answer:

   Shared Kernel means two contexts share a small part of their domain model -> Option B

4. Quick Check:

   Shared Kernel = shared small domain part [OK]

Hint: Shared Kernel means sharing a small model part [OK]

Common Mistakes:

• Confusing Open Host Service with data copying
• Thinking Customer/Supplier means no communication
• Believing Conformist ignores other models

3. Given two bounded contexts A and B where A is the Customer and B is the Supplier, what is the expected interaction pattern?

medium

A. Context B provides services that Context A consumes

B. Context A adapts to B's model without changes

C. Contexts A and B share the same database schema

D. Contexts A and B never exchange data or messages

Solution

1. Step 1: Understand Customer/Supplier relationship

   In this pattern, the Supplier context offers services or data that the Customer context uses.

2. Step 2: Analyze options

   Context A adapts to B's model without changes describes Conformist, not Customer/Supplier. Contexts A and B share the same database schema is incorrect because sharing the same database schema breaks bounded context boundaries. Contexts A and B never exchange data or messages contradicts the relationship.

3. Final Answer:

   Context B provides services that Context A consumes -> Option A

4. Quick Check:

   Customer/Supplier = Supplier provides services [OK]

Hint: Supplier provides, Customer consumes services [OK]

Common Mistakes:

• Mixing Customer/Supplier with Conformist
• Assuming shared database schema
• Thinking no data exchange happens

4. You have two bounded contexts with a Conformist relationship, but the Customer context is modifying the Supplier's domain model directly. What is the problem?

medium

A. The Conformist pattern requires sharing the same database schema

B. The Supplier context must always copy the Customer's model

C. Both contexts should merge into one to avoid conflicts

D. The Customer context should not change the Supplier's model; it should adapt to it

Solution

1. Step 1: Understand Conformist relationship rules

   In Conformist, the Customer context adapts to the Supplier's model but does not modify it directly.

2. Step 2: Identify the error in modifying Supplier's model

   Modifying the Supplier's model breaks the boundary and can cause inconsistencies.

3. Final Answer:

   The Customer context should not change the Supplier's model; it should adapt to it -> Option D

4. Quick Check:

   Conformist means adapt, not modify [OK]

Hint: Customer adapts Supplier model, does not modify it [OK]

Common Mistakes:

• Thinking Supplier copies Customer model
• Merging contexts unnecessarily
• Assuming shared database schema is required

5. You are designing a large e-commerce system with multiple teams. How should you apply bounded context mapping to ensure scalability and team independence?

hard

A. Ignore context boundaries and let teams decide data sharing ad hoc

B. Combine all domains into one large context to simplify communication

C. Define clear bounded contexts for domains like Orders, Payments, and Inventory, and map their relationships explicitly

D. Allow teams to share a single database schema to avoid data duplication

Solution

1. Step 1: Identify the need for clear domain boundaries

   Large systems benefit from dividing domains like Orders, Payments, and Inventory into separate bounded contexts.

2. Step 2: Map relationships explicitly for team independence

   Explicit mapping helps teams understand dependencies and communicate properly without tight coupling.

3. Step 3: Avoid combining domains or sharing schemas

   Combining domains or sharing schemas increases complexity and reduces scalability.

4. Final Answer:

   Define clear bounded contexts for domains like Orders, Payments, and Inventory, and map their relationships explicitly -> Option C

5. Quick Check:

   Clear contexts + explicit mapping = scalable teams [OK]

Hint: Clear contexts and explicit maps enable scalable teams [OK]

Common Mistakes:

• Merging all domains into one context
• Sharing a single database schema
• Ignoring boundaries and ad hoc sharing