PATTERN Cited by 1 source

SSTable to object store with write-through cache

Pattern

Store LSM-tree SSTables in object storage (S3, GCS, ADLS) for durability and scale, while maintaining a write-through local cache so hot reads never pay the cloud-latency tax. Every flush and compaction writes to both object storage and local cache simultaneously.

When to use

• Metadata must scale beyond single-node memory or disk capacity.
• The system must survive node/cluster loss without local disk dependencies.
• Read latency still matters for the hot path (recent or frequently accessed SSTables).
• External systems need to read SSTables directly from object storage (disaster recovery, read replicas).

Mechanism

1. Memtable flush → new SSTable written to object storage AND local cache.
2. Compaction merges SSTables → new merged SSTable written to object storage AND local cache; old SSTables deleted from both.
3. Read path: check local cache first → fall through to object storage on cache miss.

Trade-offs

• Pro: Metadata scales horizontally via object-storage capacity.
• Pro: Local cache keeps read latency low for active partitions.
• Pro: Object-storage SSTables are readable by external systems (DR, replicas).
• Con: Write amplification (two destinations per SSTable).
• Con: Cache eviction policy needed for disk-constrained nodes.
• Con: Consistency window if write to one destination succeeds and the other fails.

(Source: sources/2026-06-09-redpanda-cloud-topics-the-metastore)

Seen in

• systems/redpanda-cloud-topics-metastore — SSTables go to object storage + write-through local cache