When is a separate service justified?
Consider ownership, independent change, scaling requirements, and a stable business boundary. Splitting every database table into a service can increase coordination without creating useful independence. A modular application can be a reasonable starting point when the team and workload do not need distribution.
For our order example, payments have a different reliability and integration boundary from catalog browsing. Explain what each service owns and which contract connects them. If every small change still requires a coordinated deployment, examine whether the boundary is helping.
When would you choose a message over a direct call?
A direct call can provide an immediate response, but the caller depends on the callee's availability and latency. Messaging can decouple work in time, while introducing delivery, ordering, backlog, and observability concerns. Choose based on what the user must know immediately.
An order confirmation email may run after order acceptance. Payment authorization may need a different user-visible state. Do not label an entire system asynchronous without tracing the exact moment when the customer sees success and what that success promises.
How do you handle duplicate events?
Assume a delivery mechanism may repeat a message unless its contract establishes otherwise. Give the consumer a way to recognize already handled work and protect the relevant state transition. Deduplicating a log entry is easier than preventing a duplicate external charge.
In our exercise, the same payment-confirmed event arrives twice. The order should not be shipped twice. Explain how event identity, transaction boundaries, and the shipment operation interact. A claim of exactly-once delivery does not automatically establish exactly-once business effects across every dependency.
How do you investigate a partially completed order?
Trace a correlation identifier through the workflow and inspect durable state transitions. Distinguish waiting, failure, retry, and manual intervention states. A single red error message may not tell you whether an external operation completed before its response was lost.
If payment succeeded but inventory reservation failed, define the intended recovery: another reservation attempt, a different fulfillment path, or compensation. State who owns that decision and how the user sees the outcome. Compensation can itself fail and needs visibility.
Practice exercise
Draw a workflow containing order creation, inventory reservation, payment, and shipping. Introduce a failure after each step and describe the durable state left behind. Identify which operations can be retried safely and which require an idempotency contract.
Now add a duplicated event and a delayed event. Explain the allowed state transitions and how support staff identify a stuck order. A complete answer includes operations and recovery, not only boxes and arrows.
Rehearse this answer with Cluegent
Ask Cluegent to play the interviewer and interrupt your order-flow explanation with one dependency failure. Rehearse a response covering user impact, state, retry safety, and recovery ownership.
Try Cluegent for your practice session, then repeat the explanation without suggestions. Judge your answer by its accuracy, evidence, and response to follow-up questions.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
How should I practise this topic?
Draw a workflow containing order creation, inventory reservation, payment, and shipping. Introduce a failure after each step and describe the durable state left behind. Identify which operations can be retried safely and which require an idempotency contract.
How can Cluegent help with preparation?
Ask Cluegent to play the interviewer and interrupt your order-flow explanation with one dependency failure. Rehearse a response covering user impact, state, retry safety, and recovery ownership.