"Designed for sub-300ms voice recall" is a design target, not a marketing benchmark — and this post is about what the design actually is.
Where the budget goes
A recall request has to: authenticate, resolve the caller, fetch memory, fetch enrichment, and serialize a response. Done naively — sequential queries from a centralized server — you blow the budget before enrichment even starts. The architecture exists to make every step either parallel, cached, or skipped.
Edge-first
The API runs on Cloudflare Workers, so the request lands at a PoP near the caller rather than a fixed region. Database access goes through connection pooling at the edge (Hyperdrive), which eliminates the multi-round-trip connection handshake that kills cold serverless database calls.
The read-through cache
Repeat callers are the common case, so the contact record and recent interactions live in a Redis read-through cache keyed by tenant and phone. A warm recall's contact and memory lookup is served straight from Redis — the memory read itself skips Postgres. (Every authenticated request still opens a short tenant-scoped Postgres transaction to pin row-level security, independent of whether the memory read itself is a cache hit.) A cache miss reads the database once and repopulates — and the next call is warm again. The cache fails open: if Redis is down, requests serve from the database rather than failing.
Enrichment races, never blocks
On a cold caller, identity enrichment (Trestle, Twilio Lookup) races in parallel against a hard deadline. Whatever resolves inside the budget ships in the response; whatever doesn't is dispatched as a background job and written back asynchronously. The voice path is deadline-bounded, not zero-wait — it never blocks past that budget on a third-party API. The response tells you what happened: timing_ms is a real measured field on every response, not a published number.
Write-back off the hot path
calls/end accepts the transcript and returns; summarization happens in background jobs. The expensive intelligence — summaries, durable memory writes — is downstream of the response, never in front of it.
The result is a hot path where the slow things are either parallel or deferred. That's the whole trick — and it's why the phrase is "designed for": the architecture targets the conversational gap, and the response shows you the measurement on every single call.