AFDE Training Textbook · case chapter 36
Greenfield build: an API gateway with auth and rate limiting
Blueprint first, three milestones for auth, rate limiting, and routing, each with acceptance criteria.
Discussion before reading
How would you define the first independently verifiable milestone? Which checks need rerunning?
Write your decision, evidence and missing information before consulting the reference below.
Reference explanation · textbook case
This is a textbook case summary. Events and outcomes illustrate teaching decisions, rather than measured customer adoption or returns.
Background
An internal platform needed a single entry point. Auth, rate limiting, and routing were scattered across services. The ask: build an API gateway from scratch, one engineer, one AI agent, fixed deadline.
Process
Blueprint before code. The blueprint fixed module boundaries: request entry, auth middleware, rate limiter, routing table, upstream proxy. Each module carried its own test list.
Milestones came next:
- Milestone one: routing table and upstream proxy. Requests forward to the right service by prefix.
- Milestone two: auth middleware. Token validation, expiry handling, rejection of unauthorized calls.
- Milestone three: rate limiter. Count per client, return 429 when over the limit.
Each milestone ended at the test gate. No gate pass, no next milestone.
Key decisions
Write the acceptance criteria before the implementation. Auth acceptance: an invalid token always gets 401, and logs never hold token plaintext. Rate limiter acceptance: no race at window boundaries, and every over-limit request is rejected under load. Every criterion mapped to an executable test. Tests provide reproducible evidence; sensitive authentication logic still requires human review.
Result
The gateway shipped on schedule. All three milestones passed the test gate. Evidence for both the auth rejection path and the rate-limit boundary was kept. Blueprint, milestone records, and test results form a delivery trail the next person can walk again.