Skip to content
sysgeeks

Design a Distributed Cache (Memcache), stage 9 of 9: defend it

Defend 'best-effort eventual consistency'

Your interviewer: "Your cache can serve stale data in at least four ways. Why not a strongly consistent cache, or write-through updates, and be done with it?"

System so far· 7 parts
1234567CLIENTUsersSERVICEWeb serversSERVICEmcrouterCACHEmemcached poolCACHEGutter poolDATABASEMySQLWORKERInvalidationdaemon

Select a component to see what it is responsible for and which state it owns.

  1. 1Users → Web servers: Page request
  2. 2Web servers → mcrouter: get / multiget, delete
  3. 3mcrouter → memcached pool: Keys by consistent hash
  4. 4Web servers → MySQL: Query on miss; writes
  5. 5MySQL → Invalidation daemon: Committed deletes
  6. 6Invalidation daemon → mcrouter: Batched deletes
  7. 7mcrouter → Gutter pool: On server failure
  • Request / response
  • Bulk data
  • Asynchronous

What you need to know

0 of 1 checks done

  1. "Eventually consistent" is too vague to defend. A strong answer lists:

    • Specific guarantees: for example, a writer sees their own write; a stale value can't be cached after a newer write.
    • Specific windows of staleness: where they come from and what bounds each one.
    • What stronger consistency would cost: usually coordination on the hot path.
    • Where you'd choose differently: data that can't tolerate any staleness.

  2. Check

    What would strong consistency for every read cost a cache serving billions of reads a second across regions?