Original practice scenario: A fictional market simulator receives order acknowledgements, fills and cancellations out of order, sometimes more than once. How should its state machine behave?
Read model answer +
Represent orders as a constrained event-driven state machine, with execution quantities separate from request status. Arrival order must not erase a valid fill or apply an event twice.
Work through it
Assign stable order and event identities, record source sequence information and reject events that cannot belong to the referenced order.
Apply deduplicated events under explicit transitions, maintaining cumulative filled quantity and pending cancellation rather than assuming cancellation removes earlier executions.
Replay shuffled and duplicated streams, including partial fills during cancellation and sequence gaps; compare reconstructed state with a trusted synthetic ledger.
Tradeoffs to discuss
Waiting for missing sequence events improves certainty but delays visibility; provisional state requires clearly recorded unresolved gaps.
Common pitfalls
A cancel request is not a cancellation acknowledgement.
Do not decrement inventory twice when the same execution is redelivered.
Original practice scenario: Design a batch platform that evaluates a synthetic portfolio under many hypothetical market scenarios, allowing jobs to resume after worker failures.
Read model answer +
Make each computation identifiable by immutable input versions and scenario parameters. Reproducibility and completeness are more important than declaring success when only the fastest tasks finish.
Work through it
Partition work by stable portfolio slice and scenario range, recording the model version, random seed and numerical settings in a job manifest.
Write task outputs atomically under deterministic identities; accept repeated execution idempotently and track expected versus completed partitions.
Aggregate only a consistent manifest, validate reconciliation and numerical tolerances, and test worker crashes, stragglers and incompatible output versions.
Tradeoffs to discuss
Small partitions improve recovery and balancing but increase scheduling overhead; large partitions waste more work after failure.
Common pitfalls
Do not aggregate a mixture of model versions as one result.
Label simulated risk outputs as exercise data rather than financial advice.
