retrystorm · Learn · Interview practice · Glossary · Components

Home › Interview practice › Session Store

Session Store

Keep sessions readable through a replica outage, without ever returning an old one, by choosing replicas and quorums.

Design Inkwell Sessions, the store that remembers who is signed in. Every request reads its session, and every sign-in and refresh writes one. Two things go wrong:

  • Stale sessions: a reader refreshes a session and the next request still sees the old one, and is signed out.
  • Outages: when a machine holding the data is down, every request that needs it fails.

What it does

  • Read: look up a session.
  • Write: create or refresh a session.

Workload

A steady 400 requests a second for 20 seconds, 70% reads, over 100 busy sessions. One replica of the store is down for 4 seconds, from 8 seconds in. Replicas take about 100 ms to catch up on a write.

How to build it

The app servers, the store's latency and its replication lag are fixed. The store is already on the canvas as sessions, with one copy of each partition. You choose how many replicas it keeps (replicas, N), how many a write must reach before it is acknowledged (write_quorum, W) and how many a read asks (read_quorum, R).

  • A write goes to every live replica, and is acknowledged after the W fastest have it.
  • A read asks R live replicas, waits for the slowest of them, and returns the newest value it sees.
  • When R + W is greater than N, a read always overlaps the latest write.
  • An operation fails if fewer replicas are up than its quorum needs.
  1. Build the path: the client, the load balancer, an app server, the store. Run it as it is, and look at the failures when the replica is down.
  2. Keep every request working through the outage, and never return an old session.
  3. Then give the store only the replicas it needs.

Part of Chapter 29: Quorums.

About · Contact · Privacy · Terms of use