Design a read-heavy API with caching and etags
PremiumAPI designMedium
- HTTP caching
- Etag
- Conditional requests
Quick answer
This API design interview question asks you to design a read-heavy API with caching and etags. Aim for a design that exposes a clear, consistent and safe interface, then explain the resources, requests, responses and error handling. Interviewers want to see how you name resources, version the interface and handle failure cases.
The problem
Design a read-heavy public API with caching and ETags for live sports scores, like the data feeds behind cricket and football apps. During a big final, reads jump to 1 million per second. The hard parts are serving almost every read from the CDN while live scores stay under 5 seconds stale.
A sports data company's REST API serves fixtures, live scores, player stats and standings to thousands of apps, websites and bots. During a big cricket final reads jump to 50 times normal and the origin servers fall over, while some clients still see a score that is 2 minutes old. Every response must say how long it may be cached, and clients must be able to cheaply ask "has this changed?".
What must a read-heavy API with caching and etags do?
- Live match: Score, overs or minutes, status and last events, updated every few seconds.
- Change checks: Clients can poll a resource and get an empty 304 when nothing changed.
How well must it do it?
- Freshness: Live scores no more than 5 seconds stale at the edge; stats and standings within 1 minute of a change; history may be cached for days.
- Origin protection: At least 98% of reads served by the CDN during peaks.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- HTTP caching
- Etag
- Conditional requests
- Cache control
- CDN caching
- Cache invalidation
How you’ll practise
- Use cases
- Resources
- Endpoints
- Errors, auth and limits
- Versioning
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any API design round.
- Starts from the clients and the use cases
- Names resources and operations consistently
- Defines request and response shapes and status codes
- Covers authentication, rate limits and idempotency
- Plans pagination, filtering and versioning
- Explains how clients learn about and recover from errors
Questions people ask about this interview question
- Which design type is this question?
- It is an API design question. You design a read-heavy API with caching and etags and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the clients, the main use cases and the resources they need. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team