How the interviewer opens it
“Design an API gateway that gives clients one entry point for services with different protocols. It must route requests and apply authentication and request policies. The gateway can add at most 10 ms of latency at p99.”
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
- Scale
- Request mix and size
- Latency and availability
- Protocols
- Identity
- Policy changes and consistency
- Durability
- Request limits
- Service failures
- Other 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
- Route requests to the correct service
- Authenticate callers and enforce route access
- Apply tenant quotas, body limits, and request deadlines
- Translate between HTTP JSON APIs and unary gRPC APIs
Usually out of scope
- Build an identity provider
- Implement service business logic
- Provide global traffic control or a full service mesh
- Support streaming APIs and WebSocket connections
- Calculate customer bills
What interviewers ask about
- Policy changes
- A gateway can receive fresh token revocations while it retains old route permissions. A rollback can also restore access that an operator revoked.
- Identity and tenant limits
- Local checks avoid remote dependencies. Uneven traffic and stale identity data can still break access rules or let tenants exceed their quotas.
- Shared request capacity
- A slow service holds gateway resources long after admission. One tenant or service can exhaust capacity that unrelated requests need.
- Protocol behavior
- HTTP JSON and gRPC differ in fields, errors, metadata, and cancellation. Incorrect translation can change API meaning or expose internal details.
Common mistakes
- Places a shared database or identity call on every request without a capacity and failure plan.
- Treats fresh token data as proof that cached route policies remain safe.
- Ignores quota multiplication across the fleet and uneven tenant traffic.
- Uses unbounded queues, response buffers, or service connections.
- Retries unsafe writes or resets the deadline on each retry.
- Treats protocol translation as a format change without a public error contract.
The bar by level
- Senior (L5/E5)
- Separates control and request paths. Binds security freshness to applied access rules. Handles quota error, service isolation, bounded resources, protocol contracts, and safe retries.
- Staff (L6+/E6+)
- Quantifies capacity after zone loss and quota error across the fleet. Proves the revocation bound through partitions and rollback. Defines safe release and recovery procedures.