Staff / expert · Architecture and systems
Design a rate-limited job platform
How would you design a multi-tenant Go job service at 100,000 jobs per minute?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Clarify job duration, payload size, ordering, maximum queue age, durability, tenant isolation and acceptable duplicate execution. Requests per minute alone do not determine CPU, storage or concurrency requirements.
Bound admission per tenant and globally, persist accepted work before acknowledging according to the promised durability, and use leases with recovery. Workers must make side effects idempotent because lease expiry and crashes can permit re-execution.
Estimate active work using arrival rate × service time, then account for burst headroom and dependency limits. Track queue age, throughput, retry volume, saturation and outcome, and rehearse overload and worker loss. Prefer the simplest topology that meets those measured constraints.
Common trap
A Redis lock or a large worker count is not a complete scheduling, durability or fairness design.
Try it
Jobs take two seconds on average. Estimate average active jobs and explain why that is not the final worker count.
Worked solution
100,000/60 is about1,667 jobs/second; at2 seconds, about3,334 jobs are active on average in a stable system. Tail durations, CPU/I/O mix, quotas, retries and headroom determine limits. If capacity is lower than intake, queue age grows without bound unless admission changes.
Change the constraint
What do you promise a client when its acceptance response is lost after the job was persisted?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.