Bounded context mapping in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Bounded Context Relationships

In microservices architecture, bounded contexts define clear boundaries for domain models. Which of the following best describes the Shared Kernel relationship between two bounded contexts?

A One bounded context copies data from another asynchronously without coordination.

B One bounded context completely depends on another and cannot function without it.

C Bounded contexts are completely independent with no shared code or data.

D Two teams share a small subset of the domain model and collaborate closely on it.

💡 Hint

Think about when two teams need to work together on a small part of the domain.

The Shared Kernel pattern means two bounded contexts share a small, well-defined part of the domain model and collaborate closely to keep it consistent.

❓ Architecture

intermediate

Choosing the Right Integration Pattern

You have two bounded contexts: Order Management and Inventory. The Order Management context needs to know when inventory levels change but should not block its operations waiting for Inventory. Which integration pattern fits best?

A Shared Database where both contexts read and write the same tables.

B Direct synchronous REST API calls from Order Management to Inventory.

C Event-Driven Integration where Inventory publishes events asynchronously.

D Batch data export from Inventory to Order Management once a day.

💡 Hint

Consider loose coupling and asynchronous communication.

Event-driven integration allows Inventory to publish changes asynchronously, so Order Management can react without blocking.

❓ scaling

advanced

Scaling Bounded Contexts Independently

You have two bounded contexts: Payments and Notifications. Payments have high traffic during sales, but Notifications have steady low traffic. What is the best approach to scale these contexts?

A Deploy each bounded context as separate microservices and scale them independently.

B Deploy both contexts on the same server and scale the server vertically.

C Combine both contexts into one service to simplify scaling.

D Use a shared database to balance load between contexts.

💡 Hint

Think about independent scaling and resource optimization.

Deploying bounded contexts as separate microservices allows scaling each independently based on their load.

❓ tradeoff

advanced

Tradeoffs in Context Mapping: Customer-Supplier vs. Conformist

Between two bounded contexts, Billing and Customer Support, Billing is the authoritative source of customer data. Customer Support must use Billing's data but cannot change it. Which relationship fits best and what is a key tradeoff?

A Conformist: Customer Support depends on Billing's model and must adapt to its changes.

B Customer-Supplier: Customer Support can modify Billing's data freely, risking inconsistency.

C Shared Kernel: Both share and co-own the customer data model equally.

D Separate Ways: Both contexts maintain independent customer data without coordination.

💡 Hint

Consider who controls the data and who must adapt.

Conformist means one context (Customer Support) depends on another's (Billing) model and must conform to its changes, which can cause tight coupling.

❓ estimation

expert

Estimating Data Consistency Delay in Eventual Consistency

In a microservices system with bounded contexts communicating via asynchronous events, the Inventory service publishes stock updates. The Order service consumes these events to update availability. If Inventory publishes 1000 events per second and network latency plus processing adds 200ms delay per event, estimate the maximum delay before Order sees the latest stock update.

A At least 1 second, due to event batching and processing overhead.

B 200 milliseconds, because each event is processed immediately after network delay.

C 200 seconds, because 1000 events per second cause a backlog of 200ms each.

D Cannot estimate without knowing Order service processing speed.

💡 Hint

Focus on per-event delay, not total event volume backlog.

The maximum delay per event is network plus processing time (200ms). Since events are processed continuously, the delay before Order sees an update is about 200ms.

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