Openai·Mobile Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

System design round at OpenAI for a mobile engineer role. The question was one big sprawling prompt about quota handling for a GPT chat product, which sounds focused until you realize it touches API contracts, client UX, content-type billing, and edge cases all at once.

Questions Asked (1)

Design the full error-handling flow for when a free-tier user hits their message quota on a GPT chat service. This includes the API contract (HTTP status, error codes, retry-after headers, upgrade hints), how the server tells quota exhaustion apart from rate limiting, idempotency, client-side UI behavior, how different content types (text, image, voice, file) consume quota differently, and edge cases like mid-stream responses getting cut off.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

This felt like four questions stapled together and I kind of panicked at the scope.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by distinguishing quota exhaustion from rate limiting at the API contract level, then walk through the full lifecycle: server detection, error response design, client handling, and edge cases. Emphasize idempotency and content-type-specific quota consumption as key design decisions, and close with trade-offs around UX and upgrade nudges.

Pro tip: Treat quota exhaustion as a business event, not just an error—design the response to include upgrade hints and usage metadata so the client can render a compelling paywall without extra round trips. Also, always make quota checks idempotent and atomic to avoid race conditions in distributed systems.

1. Define the API contract for quota exhaustion

Specify HTTP 402 Payment Required (or 429 with a distinct error code) and include a machine-readable error code like 'quota_exceeded', along with Retry-After (if applicable) and upgrade_url. Distinguish from rate limiting by using different error codes and status semantics.

2. Differentiate quota exhaustion from rate limiting

Explain that rate limiting is temporary and per-time-window, while quota exhaustion is a hard limit for the billing period. Use separate error codes (e.g., 'rate_limit_exceeded' vs 'quota_exceeded') and different Retry-After semantics (seconds vs. reset timestamp).

3. Ensure idempotency and atomic quota checks

Describe how to make quota consumption idempotent using idempotency keys, and how to atomically decrement quota in a distributed system (e.g., using Redis Lua scripts or database transactions) to prevent double-spending.

4. Design client-side UI behavior

Outline how the mobile app should handle the error: show a non-blocking banner or modal with clear messaging, display remaining quota, and provide a direct upgrade path. For mid-stream cutoffs, gracefully terminate the stream and show a retry/upgrade prompt.

5. Handle content-type-specific quota consumption and edge cases

Explain that different content types (text, image, voice, file) consume quota at different rates (e.g., tokens vs. compute units). Address edge cases like mid-stream responses getting cut off, partial quota consumption, and how to reconcile usage.

Key Points to Mention

Use HTTP 402 Payment Required or 429 with a distinct error code like 'quota_exceeded' to differentiate from rate limiting.
Include Retry-After header only for rate limiting; for quota exhaustion, provide a reset timestamp or upgrade URL.
Implement idempotency keys to prevent duplicate quota consumption on retries.
Design client UI to show a clear upgrade path and remaining quota, with graceful handling of mid-stream cutoffs.
Define quota consumption units per content type (e.g., text tokens, image generations, voice minutes, file size).
Ensure atomic quota decrements and handle race conditions in distributed environments.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.