Design Google Forms: system design interview question

How the interviewer opens it

“Design a service where people create forms, submit responses, and view result totals. A form can become popular very quickly, but the service must not lose accepted responses.”

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

Questions and form changes
Scale and request mix
Peak traffic
Response size and retention
Latency and result freshness
Durability and availability
Retry behavior
Result meaning
Access and abuse
Other boundaries

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 and publish forms
Accept responses without losing acknowledged data
Prevent duplicate responses from request retries
Show response counts and question totals for each revision

Usually out of scope

File uploads
Conditional question paths
Payments
Custom reports
Service across multiple regions

What interviewers ask about

Response acceptance: A timeout leaves the client uncertain. A server can also fail after durable acceptance but before result totals change.
A sudden rise in submissions: One form can generate half the peak traffic. A partition for each form can fail while most of the database remains idle.
Result accuracy and delay: Worker failures can inflate totals. Different buckets can also advance at different rates, so a recent snapshot can still contain old results.
Changes to a published form: Respondents can keep old pages open after an owner changes a form. The service must preserve answer meaning and enforce the replacement deadline.

Common mistakes

The server acknowledges responses before durable storage.
The design places all responses for one form in one partition.
The submission path updates every result counter before it returns.
The design counts request retries as new responses.
The owner changes a published form without preserving earlier revisions or enforcing their deadlines.
The result page reports its refresh time as proof that its totals include recent responses.

The bar by level

Senior (L5/E5): Separates durable acceptance from result updates. Prevents duplicate writes and contributions. Distributes popular forms across partitions. Handles revision deadlines and worker recovery.
Staff (L6+/E6+): Defines inclusion guarantees across buckets. Proves deadline enforcement despite stale metadata. Quantifies recovery capacity, zone failure behavior, and fairness during overload.

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 Google Forms
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service where people create forms, submit responses, and view result totals. A form can become popular very quickly, but the service must not lose accepted responses.”

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

Questions and form changes

Scale and request mix

Peak traffic

Response size and retention

Latency and result freshness

Durability and availability

Retry behavior

Result meaning

Access and abuse

Other boundaries

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 and publish forms
Accept responses without losing acknowledged data
Prevent duplicate responses from request retries
Show response counts and question totals for each revision

Usually out of scope

File uploads
Conditional question paths
Payments
Custom reports
Service across multiple regions

What interviewers ask about

Response acceptance

A timeout leaves the client uncertain. A server can also fail after durable acceptance but before result totals change.

A sudden rise in submissions

One form can generate half the peak traffic. A partition for each form can fail while most of the database remains idle.

Result accuracy and delay

Worker failures can inflate totals. Different buckets can also advance at different rates, so a recent snapshot can still contain old results.

Changes to a published form

Respondents can keep old pages open after an owner changes a form. The service must preserve answer meaning and enforce the replacement deadline.

Common mistakes

The server acknowledges responses before durable storage.

The design places all responses for one form in one partition.

The submission path updates every result counter before it returns.

The design counts request retries as new responses.

The owner changes a published form without preserving earlier revisions or enforcing their deadlines.

The result page reports its refresh time as proof that its totals include recent responses.

The bar by level

Senior (L5/E5)

Separates durable acceptance from result updates. Prevents duplicate writes and contributions. Distributes popular forms across partitions. Handles revision deadlines and worker recovery.

Staff (L6+/E6+)

Defines inclusion guarantees across buckets. Proves deadline enforcement despite stale metadata. Quantifies recovery capacity, zone failure behavior, and fairness during overload.