Casebook/Case 03
Data & platform

A gigascale feature store with Redis

Serving fresh features at large scale while controlling key design, memory, availability, and operational load.

Reported by the primary sourceFACT LAYER

What we can attribute directly

DoorDash described an online feature store built with Redis for high-throughput, low-latency access.

The article discusses feature ingestion, naming, storage, and operational scale.

Read DoorDash Engineering — Feature Store Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Very high QPS, bounded latency, high availability, memory cost, and evolving feature schemas.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Feature retrieval becomes the dominant inference dependency and individual team conventions create collisions.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Feature retrieval becomes the dominant inference dependency and individual team conventions create collisions.

Investigation

Break p99 into client, network, serialization, key lookup, payload, and retry time; inventory key cardinality and TTL behavior.

DIAGNOSTIC EXERCISE

A new model doubles payload size. Estimate the impact on memory, network transfer, and tail latency before rollout.

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

An online store without explicit entity, version, freshness, and capacity contracts becomes shared hidden state.

FIX

Standardize key and namespace contracts, compact payloads, isolate load, and make freshness observable.

Rollout

Shadow reads, sample value parity, ramp traffic by model, and retain default-safe feature behavior.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • One unbounded document per entity.
  • Synchronous fan-out to every upstream source at prediction time.
06 · Monitoring after the fix

Make recurrence visible early.

01

Store p50/p99 and error rate

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Key cardinality and memory

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Feature age and default rate

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

Online feature serving is a latency-critical database product with ML semantics.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.