Work · Architect · Build
The dual cache: every read from cache, sold-out items still accurate
Peak-hour database load from ~100% to ~5% on a high-traffic menu at a YC S17 food-tech startup, without ever showing a sold-out item as available.
- Role
- Full-Stack Software Engineer
- Where
- Dahmakan (YC S17), Kuala Lumpur
- When
- Aug 2018 to Oct 2020
Context
Dahmakan sold meals through an app. At lunch the menu was read by everyone at once, and every read hit the database. The database sat at ~100% at peak, and the menu is the one page that cannot be slow or wrong: a sold-out dish shown as available is a cancelled order.
The constraint
A plain cache solves the load and breaks the accuracy. Stock changes every minute at peak; a cache with a time-to-live either serves stale stock or expires so often that the database is back where it started.
The decision
Two caches instead of one. Cache A serves every read. Cache B is refreshed continuously from the database in the background, and the two swap the moment B is fresh. Readers never wait on the database, and the serving copy is never older than one refresh cycle, so sold-out items stay accurate.
Outcome
All reads served from cache with continuous background refresh; peak-hour database load fell from ~100% to ~5%. The backend was Java Spring Boot on MongoDB, built under test-driven development with 1,200+ Mockito test cases maintained over the two years.