🔌 API Request Pipeline

About this simulation

Every well-built API sits behind the same set of checkpoints: an API gateway that receives every call, an authentication step that verifies an API key or token, a rate limiter that protects the backend from being overwhelmed, a versioned service that implements the actual business logic, and a database that persists or returns data. This scene animates that pipeline as glowing packets, colour-coded by HTTP method, moving between the nodes — and shows exactly where and why a request gets rejected.

How it works

• Gateway — every request lands here first; it enforces authentication and rate limits before anything reaches your code.
• Auth check — when "Require API key" is on, each packet detours up to the auth service to be validated; turn it off to see unauthenticated calls sail through — a real gateway would instead return 401.
• Rate limiter — if the request rate exceeds the configured limit, excess packets are rejected with 429 Too Many Requests instead of reaching the backend.
• Versioned backend — requests route to the v1 or v2 service node depending on the selected API version, a common pattern for evolving an API without breaking existing clients.
• Database — the backend reads or writes data, then a response packet travels back along the same path to the client.

Controls

• Request rate — how many requests per second the client fires.
• HTTP method — GET, POST, PUT or DELETE; each is colour-coded on the packets.
• API version — routes traffic to the legacy (v1) or current (v2) backend node.
• Rate limit — the gateway's maximum accepted requests per second before it starts returning 429s.
• Require API key — toggles whether requests must pass the auth service before reaching the backend.

Did you know?

Most production REST APIs enforce rate limits using algorithms like the token bucket or sliding-window counter — the same conceptual "budget per second" this simulation's rate limiter models, just applied over real request logs instead of a slider.