Design an application platform like Heroku: system design interview question

How the interviewer opens it

“Design a managed platform that turns application source code into web services. Users can create, update, and remove applications. The platform serves many tenants.”

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

Applications and capacity
Traffic and read:write mix
Source builds
Latency
Application behavior
Tenant boundaries
Order and consistency
Availability
Durability and release history
Region and exclusions

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 applications and build executable releases from source code.
Deploy releases, restore previous releases, change instance counts, and delete applications.
Route HTTP requests to healthy application instances.
Isolate tenant code, secrets, networks, and resource use.

Usually out of scope

Custom domains
Automatic scale changes
Managed databases and persistent application disks
Functions that start for each request
Source code editors
Multiple regions
Billing and payment collection

What interviewers ask about

Application changes: A deployment spans builds, artifacts, instances, and routes. Retries and late results can restore an old release or recreate a deleted application.
Traffic during an update: The platform must change releases without sending requests to failed or incomplete instances. Routers can observe changes at different times.
Tenant boundaries: Tenants control executable code in both builds and services. Resource limits alone do not protect hosts, credentials, or private networks.
Deployment demand: Builds consume minutes of compute and produce large images. A burst can exhaust workers or delay every tenant's releases.

Common mistakes

Treats a successful image build as a completed deployment.
Builds a custom scheduler before defining application state and release behavior.
Runs untrusted build scripts beside control services.
Uses ordinary containers as the entire tenant security boundary.
Makes application requests depend on the control database.
Ignores late build results, deployment retries, and deletion races.

The bar by level

Senior (L5/E5): Defines durable deployment states and safe retries. Enforces the release order contract and handles deletion races. Sizes build concurrency and protects tenant boundaries.
Staff (L6+/E6+): Defines invariants across deployment work, routes, and resource ownership. Analyzes host compromise, tenant fairness, zone failures, and capacity costs. Explains recovery without weakening those invariants.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design an application platform like Heroku
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a managed platform that turns application source code into web services. Users can create, update, and remove applications. The platform serves many tenants.”

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.

Scope of a strong answer

Core requirements

Create applications and build executable releases from source code.
Deploy releases, restore previous releases, change instance counts, and delete applications.
Route HTTP requests to healthy application instances.
Isolate tenant code, secrets, networks, and resource use.

Usually out of scope

Custom domains
Automatic scale changes
Managed databases and persistent application disks
Functions that start for each request
Source code editors
Multiple regions
Billing and payment collection

What interviewers ask about

Application changes

A deployment spans builds, artifacts, instances, and routes. Retries and late results can restore an old release or recreate a deleted application.

Traffic during an update

The platform must change releases without sending requests to failed or incomplete instances. Routers can observe changes at different times.

Tenant boundaries

Tenants control executable code in both builds and services. Resource limits alone do not protect hosts, credentials, or private networks.

Deployment demand

Builds consume minutes of compute and produce large images. A burst can exhaust workers or delay every tenant's releases.

Common mistakes

Treats a successful image build as a completed deployment.

Builds a custom scheduler before defining application state and release behavior.

Runs untrusted build scripts beside control services.

Uses ordinary containers as the entire tenant security boundary.

Makes application requests depend on the control database.

Ignores late build results, deployment retries, and deletion races.

The bar by level

Senior (L5/E5)

Defines durable deployment states and safe retries. Enforces the release order contract and handles deletion races. Sizes build concurrency and protects tenant boundaries.

Staff (L6+/E6+)

Defines invariants across deployment work, routes, and resource ownership. Analyzes host compromise, tenant fairness, zone failures, and capacity costs. Explains recovery without weakening those invariants.