API Rate Limiter Design Under Constraints at Cerbo

What You'll Be Doing

You're a software engineer on a growing B2B SaaS platform. Last week, a single client's automated sync job consumed 40% of your API capacity for three hours, causing elevated latency and timeout errors for other clients. The engineering team has been asked to fix this before it happens again.

Build a rate-limiting middleware layer that sits between incoming requests and API handlers, enforcing configurable limits before requests reach application logic. This is a proof-of-concept — focus on engineering judgment and trade-offs, not production polish. You have 30 minutes for the build phase.

Requirements:

Per-client rate limiting — configurable per-org thresholds (e.g. 100 req/min standard, 500 premium)
Per-endpoint rate limiting — stricter limits on write endpoints (POST, PUT, DELETE) than reads (GET)
Meaningful error responses — 429 status, which limit was hit, and a Retry-After header
Configurable limits — defined in a config object or file; adjustable without code changes

Constraints:

In-memory only — no Redis, no external cache, no database. Address what breaks under this constraint and what changes when infrastructure becomes available.
Any language or framework — language choice is not scored; engineering judgment is.
Must work as middleware — implement as a middleware layer or decorator/interceptor pattern, not a modification to every individual route.
Async-first communication — your README is how the team understands your work. Write it for someone reading at 11pm who can't ask follow-up questions.
Demonstrate known failure modes — articulate what breaks (process restarts, horizontal scaling, memory growth); don't pretend limitations don't exist.

AI usage guidance:

We expect you to use AI tools. We evaluate how you use them — not whether you use them.
Evidence of iteration, redirection, and critical evaluation scores higher than polished output with no process documentation.
The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.
Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words. We suggest that you do not read a transcript created by AI!

What You'll Accomplish

Demonstrate the ability to design and implement a middleware component that solves a real-world API reliability problem within a constrained timeframe.

Show engineering judgment about trade-offs when building with deliberate infrastructure constraints — what works now, what breaks at scale, and what the migration path looks like.

Articulate known failure modes honestly rather than ignoring them — engineers who own systems in production need to know what will break before it breaks.

Communicate technical decisions clearly in writing and on video for an async, remote team that can't ask follow-up questions.

Show how you collaborate with AI coding tools — directing, evaluating, and iterating on AI-generated output rather than accepting it uncritically.

How Your Work Will Be Scored

Core Technical Execution (30%) Agentic Development & AI Collaboration (25%) Strategic Judgment & Production Ownership (20%) Communication & Async Clarity (15%) AI Fluency (10%)

What to Submit

Code Artifact

DocumentRequired

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Working proof-of-concept: the middleware, configuration schema, and a minimal integration example (a few sample routes).

Video Walkthrough / Demo

Video · 8-10 minutesRequired

Format: .mp4, .mov, .webm

8–10 minutes. MP4 or MOV, uploaded directly on the platform.

• Problem summary and approach (60 seconds)

• Code walkthrough — middleware implementation, per-client and per-endpoint limiting, integration with sample API (2–4 minutes)

• Failure modes — what breaks under scale, what changes with distributed infrastructure (1–3 minutes)

• Mandatory AI question: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. (1–2 minutes)

• What you'd do differently with more time (30–60 seconds)

Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words.

README (three required sections)

DocumentRequired

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Section A: Architecture & Trade-offs (300–500 words)

Algorithm choice and why. Trade-offs — what it handles well, where it breaks down. How per-client and per-endpoint limiting interact. What you'd change with more time. Write for a teammate reading asynchronously.

Section B: Production Readiness Plan

B1 — Failure Modes & Scaling Plan (200–300 words): (1) What happens on process restart — fresh quotas, acceptable? (2) What breaks across multiple server instances and what infrastructure fixes it? (3) Memory growth as clients scale — when does it become dangerous, and what monitoring catches it first?

B2 — Required reasoning question (answer without AI assistance): Describe a scenario where an AI coding assistant gives a plausible but incorrect answer for this problem. What would the incorrect output look like? How would you catch it before acting on it?

Section C: AI Usage Log (Mandatory)

This is not a trick. For each significant AI interaction, note: what you asked / what it gave you / what you kept, changed, or rejected — and why. Three interactions is sufficient. The log does not need to be exhaustive.