Stop 3 · Why we use Redis
One real system, WeShipItNow, and the three places it uses Redis — plus how to describe them in an interview.
The three places Redis is actually used in one real system
WeShipItNow takes an origin ZIP, a destination ZIP, the package weight and dimensions, and a ship date. It then asks USPS, FedEx, UPS, and Amazon for quotes at the same time, compares them, and lets the user buy a label and track the parcel. is used in three places here, and each one answers the same question: why Redis, and not something else? Switch tabs between the three scenarios below. Each one plays step by step.
First, find what is actually slow
One quote calls four at the same time: USPS around 300ms, FedEx around 800ms, UPS sometimes over a second, and Amazon is no faster. The cannot compare prices until the slowest one answers, so a single quote takes roughly a second. The same package is also queried again and again: the user refreshes, goes back a page, or a colleague checks the same route. The rate does not change over such a short window. A value that is expensive to compute and requested repeatedly is the textbook case for a .
- Lead with this one: cache-aside over carrier quotes, turning a one-second external call into a millisecond read from memory.
- Bring up the details yourself: accountId in the key, a short TTL, and a fallback that calls the carriers directly when Redis is unavailable. Those details are what an interviewer is listening for.
- Don't treat the Apollo Client cache and the Redis cache as the same thing. Only the server-side cache stops repeated carrier calls.
- Don't claim zero latency. A cached quote can be up to one TTL out of date, so you still re-check the price before buying a label. The cache speeds up reads; it is not the authoritative price.