Synchronous vs Asynchronous Cache Invalidation for Feed Consistency

Trade-off Context

Facebook's distributed Memcached layer uses a delete-then-update invalidation pattern backed by a lease mechanism to prevent stampedes. For non-critical feed data the platform favors availability and partition tolerance, accepting a window where stale results can be served after a database write but before the invalidation propagates across regions.

Decision Point

Engineers configuring a new feed-ranking service must choose between two documented invalidation paths: a synchronous RPC that blocks the write until the cache deletion is acknowledged by the quorum of replicas, or an asynchronous fire-and-forget deletion that returns immediately and relies on eventual consistency. The synchronous path adds measurable write latency (typically 2–5 ms per hop) but narrows the staleness window; the asynchronous path keeps write latency low but extends the period during which readers in distant data centers may see outdated rankings.

Constraints

• Lease timeouts are internal and not exposed for tuning.
• Consistency requirements differ per feed type (e.g., News Feed vs. Marketplace).
• Cross-region replication lag varies with network conditions.

Which invalidation strategy minimizes user-visible staleness for a high-traffic, globally distributed feed without exceeding a 99th-percentile write latency budget of 10 ms? How does the choice interact with the lease mechanism during cache-miss storms? Are there documented per-feed-type defaults that can be overridden safely?