How the interviewer opens it
“Design a multi-tenant service that stores and retrieves large objects. The service must provide high durability, scale horizontally, and continue service during partial infrastructure failures.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Implementation boundary
- Stored data and object size
- Traffic and read:write ratio
- Object behavior
- Latency
- Consistency and retries
- Durability and failure domains
- Repair target
- Tenant protection
- Excluded features
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create, replace, and delete objects in isolated tenant namespaces.
- Read complete objects or byte ranges.
- Resume large uploads after client failures.
- Preserve acknowledged objects through node, rack, or single-zone failures.
Usually out of scope
- Object version history
- Object list operations
- Cross-region replication
- A new identity service
- An existing object store as the data backend
What interviewers ask about
- Object visibility
- A large upload spans many requests. A crash can separate stored bytes, object visibility, operation results, and quota changes.
- Data loss and recovery
- Replica count alone does not establish durability. Placement, persistence, corruption detection, and repair speed determine which failures the service survives.
- Capacity growth
- New capacity changes data locations while transfers continue. Stale locations and old commands can cause failed reads or unsafe deletion.
- Tenant boundaries
- Large transfers consume disk, network, and temporary space. Tenant protection must cover access, resource use, and encryption keys.
Common mistakes
- Uses an existing object store instead of designing the object data layer.
- Calculates request rates but ignores transfer bandwidth and replica traffic.
- Separates publication, operation results, and quota changes without a safe recovery protocol.
- Adds replicas without defining failure domains, durable acknowledgment, or repair capacity.
- Deletes bytes without protecting active reads and incomplete uploads.
- Promises permanent delete retry safety after discarding idempotency records.
The bar by level
- Senior (L5/E5)
- Couples publication, operation results, and quota changes across crashes. Bounds delete retry safety. Defines safe cleanup and key use. Quantifies transfer and repair capacity.
- Staff (L6+/E6+)
- Defines authority during partitions and safe placement changes. Resolves quota hotspots without weakening limits. Evaluates correlated failures, key outages, repair exposure, and recovery costs.