The data model is the design

Before you start

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Why it matters

Every API request needs a fast yes-or-no decision before expensive work begins. Two simultaneous requests from the same user must not both spend the last allowance, and an unavailable limiter must not accidentally become a full API outage. For a 100-requests-per-minute user, the check must be atomic, add less than one millisecond, and have an explicit down-state policy.

Every API request asks a limiter whether this user may proceed. The limiter allows 100 requests per minute.

For user api:123 and a 100-per-minute rule, define allow(key) at the gateway, store that user’s count or token state atomically, return 429 with Retry-After on deny, and choose fail-open behavior for a store outage.

The gateway calls allow("api:123") before forwarding. An allowed result continues to the service; a denied result becomes 429 Too Many Requests with Retry-After, so clients know when another attempt may succeed.

The shared entry for api:123 holds either the current-minute count or tokens plus last_refill. The check and update happen atomically so two gateways cannot consume the same final token. If the store is down, a public API can fail open and alert; a security boundary may choose fail closed.