Design an artifact store on K8s and Cassandra

Quick 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.

Design an artifact store on K8s and Cassandra

Company: NVIDIA

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

You operate a Java web API on Kubernetes backed by a Cassandra cluster that stores artifacts identified by a user-provided name. The system must ensure each artifact name is created exactly once. a) How do you handle concurrent Create requests so only one succeeds? Specify the primary key schema, idempotency keys, and the concurrency-control mechanism (e.g., Cassandra LWT/IF NOT EXISTS, unique-name reservation rows, or a distributed lock), including retry behavior and failure modes. b) If a Delete capability is later introduced, how do you model deletes and subsequent re-adds to avoid races and duplicates (e.g., soft deletes with tombstones, grace periods/TTLs, name reuse policy, and tombstone compaction considerations)? c) How do you design and optimize the Read API for latency and throughput while controlling consistency (e.g., read consistency levels, caching, pagination, read repair, replication factors, hot-partition mitigation, and fallback strategies during partial outages)?

Quick Answer: 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.

|Home/System Design/NVIDIA
NVIDIA logo
NVIDIA
Sep 6, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
4
0

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).

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...