Design a Random Number Generation API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design a service exposing REST and streaming endpoints for generating random numbers at scale. Specify API contracts and versioning, entropy sources and CSPRNG vs. PRNG choices, seeding and reproducibility, rate limiting and quotas, multi-tenant isolation, security and abuse prevention, observability, deployment and scaling strategy, and SLAs for latency and availability.
Quick Answer: Design a Random Number Generation API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
System Design: Random Number Service (REST + Streaming)
You are designing a high-scale service that generates random numbers and exposes both REST and streaming interfaces. The service must support secure and non-secure modes, per-tenant isolation, and strong observability. Assume internet-facing clients and multi-region deployment.
Specify the following:
API Contracts and Versioning
Define REST endpoints for generating bytes, integers, and floats (bulk requests). Include request/response schemas, error codes, idempotency, and content types.
Define streaming endpoints (e.g., SSE, WebSocket, gRPC) for continuous random data. Include connection setup, backpressure, and chunking.
Describe versioning strategy and backward compatibility guarantees.
Entropy Sources and RNG Choices
Choose CSPRNG(s) for secure mode and PRNG(s) for fast mode. Justify choices and any FIPS-validated options.
Describe entropy sources (OS/HW) and reseed strategy.
Seeding and Reproducibility
Define how clients can request deterministic sequences (e.g., seed + stream_id + offset).
Describe unbiased range mapping for integers, precision for floats, and guarantees for identical output across regions/instances.
Rate Limiting, Quotas, and Multi-Tenant Isolation
Specify per-tenant and per-token rate limits and quotas, burst behavior, headers, and error handling.
Describe isolation of RNG state and keys so tenants cannot affect or infer each other’s output.
Security and Abuse Prevention
Define authentication/authorization, transport security, request validation, and DDoS/WAF controls.
Address storage/handling of seeds and audit considerations.
Observability
Define metrics, logs, and traces. Include RNG health checks, entropy pool telemetry, and quality testing (e.g., periodic Dieharder/NIST STS).
Deployment and Scaling Strategy
Propose a multi-region architecture, autoscaling, failover, and zero-downtime rollout plan.
Include worker design (e.g., vectorized generation, prefetch buffers), state placement, and stream stickiness.
SLAs/SLOs
Propose latency and availability targets for REST and streaming, including startup latency, sustained throughput, and error budgets.
Assume peak scale of 100k REST requests/sec per region and up to 5 Gbps of streaming throughput per region. Note any assumptions you make.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?