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.