ORIGINAL COMPANY-CONTEXT PRACTICE
Replay game events without duplicating player rewards
Original practice scenario: A hypothetical online game processes achievement events and awards a reward. Servers retry after a timeout, and old events can be replayed after recovery. Design a safe handler.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Bind the award to a unique achievement occurrence and commit its outcome with the player-state change. Delivery retries must not create new economic events inside the game.
Work through it
- Define event identity, player identity and achievement version, validating the server-authorized event rather than trusting a client-supplied reward amount.
- Within the player-state boundary, record the processed occurrence and apply the reward atomically; return the previous result for an identical retry.
- Handle out-of-order prerequisites and replay from checkpoints, preserving a correction path for an invalid event already processed.
Tradeoffs to discuss
- Serializing updates per player simplifies consistency but creates hot-player limits; sharding requires careful coordination for rewards spanning shared teams or inventories.
Common pitfalls
- A timestamp or achievement name alone may not identify a repeatable occurrence.
- Test a failure after reward commitment but before acknowledgment, and reject conflicting payloads under the same event identity.