Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Define booking states, hold and cancellation rules, deadlines, customer price guarantees, and which provider operations support idempotency or status lookup. Clarify acceptable partial fulfillment.
Establish scale assumptions
- Estimate concurrent in-flight workflows from worst-case provider delay, not request rate. Size durable timers, reconciliation queries, and manual review for multi-hour ambiguity.
Functional and non-functional requirements
- Persist every state transition, avoid duplicate charges or reservations, surface honest progress, compensate according to policy, and allow safe operator actions. Restarts and deployments cannot lose timers.
High-level architecture
- Use a durable workflow engine or explicit state machine with per-partner adapters, idempotency records, scheduled timers, outbox events, and a reconciliation service. Keep customer-facing aggregate state separate from raw adapter details.
Data model and flow
- Commands carry booking and operation IDs; adapter results distinguish success, failure, and unknown. Provider callbacks correlate to the stored attempt and advance only valid expected states.
Consistency and transaction boundaries
- Each local transition is transactional; global completion is a saga. Compensation is provider-specific and may become a refund or support case rather than an inverse operation.
Failure modes and recovery
- On timeout, query status before retry when possible; otherwise mark unknown and reconcile. Expired holds and late callbacks use version checks so obsolete success cannot resurrect a canceled booking.
Security and privacy
- Tokenize payment and identity data, verify callbacks, scope adapter credentials, and redact provider payloads from general logs. Operator overrides require reason and dual control for high-value actions.
Observability and SLOs
- Track time in state, provider latency and unknown rate, compensation success, late callbacks, manual-review age, and customer completion SLO. Trace every attempt by stable operation ID.
Capacity and cost
- Durable workflow history and timers are cheaper than repeated partner calls and support incidents. Archive terminal detail by policy and keep adapters isolated so one provider backlog cannot starve others.
Alternatives and trade-offs
- Central orchestration gives visibility and policy control but can become a domain bottleneck; choreography reduces central coupling but obscures long-running state. Prefer orchestration for customer-visible multi-partner journeys.
Evolution and migration
- Wrap one provider at a time behind idempotent adapters, record shadow state, and migrate new bookings before old in-flight ones. Keep a compatibility reader until every legacy booking reaches terminal state.
What Staff and Principal candidates should emphasize
- Staff candidates model unknown as a real state and explain late messages, timers, support, and compensation. They design for partner semantics instead of drawing a generic queue.
Decision trade-offs
Coordination style
Option A
Event choreography among adapters
Option B
Durable central workflow state machine
Recommendation:Use a workflow state machine when customer completion, timers, and compensation require one observable policy owner.
Timeout handling
Option A
Retry immediately
Option B
Record unknown and reconcile provider state
Recommendation:Reconcile before repeating non-idempotent or financially consequential actions; timeout is not a negative acknowledgment.
Follow-up interview questions
- 01What happens when a confirmation arrives after the customer canceled?
- 02How do you migrate workflows already in progress?
- 03When does compensation require human approval?
- 04How do you avoid one provider outage filling all worker capacity?
Common weak answers and mistakes
- 01Representing partner timeout as failure instead of unknown outcome.
- 02Assuming every successful operation has a clean inverse.
- 03Keeping timers only in process memory.
- 04Exposing raw partner states directly as an unstable customer contract.
Interviewer evaluation rubric
Uses synchronous calls and retries but cannot represent unknown outcomes, late callbacks, or compensation.
Defines a durable saga, idempotent adapters, persisted timers, reconciliation, and customer-visible states.
Handles versioned late events, provider isolation, manual review, security, migration, and policy-specific compensation.
Balances product guarantees and partner uncertainty through explicit economic and customer-service policy, not just technical orchestration.