Design an artifact store on K8s and Cassandra
Overview
This question evaluates distributed-systems and system-design competencies, including concurrency control for unique-name creation, idempotency and retry semantics, deletion modeling (soft deletes, tombstones, TTL), and read-path consistency, caching and performance when running a Java API on Kubernetes with Cassandra storage.
System Design: Exactly-Once Creation by Name on Cassandra, Deletes, and Read API Design
Context
You run a Java web API on Kubernetes backed by a Cassandra 4.x cluster. Users create artifacts identified by a user-provided unique name. The system must ensure each name is created exactly once under concurrent requests. Later, a Delete feature is added. Finally, you must design the Read API for low latency and high throughput while controlling consistency.
Assume a single region with 3 Availability Zones, NetworkTopologyStrategy, RF=3 per DC, and cross-AZ traffic allowed. Payload size fits Cassandra best practices; if not, store only metadata in Cassandra and the payload in blob storage.
Tasks
a) Creation concurrency control
- Define the table schemas and primary keys.
- Specify idempotency keys.
- Choose a concurrency-control mechanism (e.g., Cassandra LWT with IF NOT EXISTS, unique-name reservation rows, or a distributed lock), and describe retry behavior and failure modes.
b) Delete and re-add semantics
- Model deletes to avoid races and duplicates, including soft deletes, tombstones, TTL/grace period, name reuse policy, and tombstone compaction considerations.
c) Read API design
- Design and optimize the Read API for latency/throughput while controlling consistency (read CLs, caching, pagination, read repair/repairs, replication, hot-partition mitigation, and fallbacks during partial outages).
Solution
Login required