# Design a container orchestration platform like Kubernetes: system design interview question

> A fixed cluster must support resource constraints, uncertain machine failures, and application updates without unnecessary service loss.

Source: https://sysround.com/questions/design-container-orchestration-platform-like-kubernetes
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a platform that maintains the desired application state across a cluster of machines. Support container placement, failure recovery, and rolling deployments."

## What to clarify first

- Applications
- Scale
- Read and write traffic
- Placement rules
- API latency
- Failure recovery
- Consistency, availability, and durability
- Deployment behavior
- Capacity and startup
- Existing systems and exclusions

## Scope of a strong answer

Core requirements:

- Accept an application image, replica count, and resource requests.
- Place containers on machines with enough resources.
- Restore the desired replica count after container or machine failures.
- Deploy new versions within application availability limits.

Usually out of scope:

- Stateful applications and persistent volumes
- Container runtime implementation
- Custom network design
- Image builds and registry implementation
- Automatic changes to the machine count
- Isolation for untrusted customers

## What interviewers probe

### Placement decisions

Free cluster capacity does not guarantee a valid placement. Concurrent decisions can claim the same resources before containers start.

### Machine failures and return

A missing heartbeat does not prove that containers stopped. Replacements can restore service while isolated machines retain obsolete containers.

### Deployment progress

A container can run without serving traffic. Deployment decisions must respect readiness, spare capacity, small replica counts, and containers that have not stopped.

### Desired-state durability and authority

Accepted application changes must survive failures. Old controllers must not override newer decisions when a partition separates control-plane members.

## Common mistakes

- The design places containers once but does not restore the requested application state.
- The scheduler checks current utilization but ignores resource reservations.
- The controller treats a missing heartbeat as proof that a container stopped.
- Returning agents never compare their containers with current assignments.
- The deployment controller states limits but ignores pending instances, terminating instances, or readiness when it applies them.
- The API acknowledges desired-state changes before durable storage confirms them.

## The bar by level

- **Senior:** Enforces resource reservations and deployment budgets through retries and controller restarts. Handles unreachable machines and obsolete assignments. Preserves healthy containers during control-plane outages.
- **Staff+:** Defines authority across partitions and explains the limits of session epochs. Quantifies recovery after 500 machine failures. Distinguishes authorized counts from physical duplicates. Plans control-plane growth and future stateful safety without unnecessary scheduler shards.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=container-orchestration-platform


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.