Design a Client for an Unreliable Token Service
Your service needs a short-lived token from a third-party token service on every outbound call. That service is slow at times and down at others. Design the client so your own availability does not track theirs.
Cover caching, when and how a token is refreshed, what happens when many requests need a token at the same moment, how you behave while the token service is down, and the trade-off between serving a slightly stale token and failing the request.
Hints
Hint 1
Cache the token with its expiry and refresh it ahead of expiry, with jitter so a fleet does not refresh in lockstep.
Hint 2
Single-flight the refresh: one in-flight request serves every waiter; the rest reuse the current token meanwhile.
Hint 3
Circuit breaker and backoff around the token service, and a policy for the window after expiry when no refresh has succeeded.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.