How the interviewer opens it
“Design a shared service that prevents repeated side effects for the same client key within a tenant and API operation. Protection ends 24 hours after completion. Handle concurrent retries, worker crashes, and expiration of stored results.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Supported APIs
- Keys and request identity
- Scale
- Read and write mix
- Latency
- Stored results
- Consistency and durability
- Crashes and responses
- Expiration
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Identify duplicate requests within a tenant and API operation
- Coordinate concurrent attempts for the same request
- Recover after a worker crashes without repeating a committed change
- Return stored results until their expiry
Usually out of scope
- Transactions across multiple application databases
- External effects without durable duplicate protection
- Permanent duplicate protection for client keys
- Execution of application code by the shared service
What interviewers ask about
- Concurrent requests
- Several handlers can receive the same key before any result exists. The service must separate duplicate requests from conflicting input.
- Worker failures
- The application database and shared service commit separately. A crash can leave a completed effect without a stored result.
- Result expiration
- Result expiry changes the promise to clients. Old workers and delayed deletion can still affect a reused key.
Common mistakes
- The design treats a shared lock as complete protection against repeated side effects.
- The design ignores the gap between the application commit and result publication.
- The design treats lease expiry as proof that a worker stopped.
- The design accepts different input under an existing key.
- The design expires unresolved operations without checking their outcome.
- The design deletes receipts while old attempts can still execute.
The bar by level
- Senior (L5/E5)
- Closes the crash gap with an atomic application receipt. Specifies lease takeover, stale-owner rejection, response recovery, and safe result expiry.
- Staff (L6+/E6+)
- Defines the guarantee across both stores and every failure boundary. Resolves receipt retention against late execution. States impossible guarantees and sets explicit integration contracts.