We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
A company with 30 microservices had authentication logic in every service. Some validated JWTs correctly. Some only checked expiration but not the signature. Two services accepted tokens from any issuer. One service had at 1,000 requests per minute. Another had no rate limiting at all.
When a security audit found these inconsistencies, the remediation required changes across 30 codebases, coordinating deployments, testing, and rollback plans for each one. Three months of work. During the audit, an attacker was already exploiting the service that did not validate signatures, forging tokens and accessing customer data.
Stripe processes billions of API requests per year through their gateway layer. Every request passes through the same authentication, rate limiting, and validation pipeline before reaching any backend service. One implementation. One audit surface. One place to fix a vulnerability.
| Function | What It Does | Why At the Gateway |
|---|---|---|
| Authentication | Verify /API key/OAuth token | One implementation, consistent across all services |
| Limit requests per client/IP/endpoint | Protect all backend services from abuse with shared counters | |
| Request validation | Check request size, content-type, schema | Block malformed requests before they consume backend resources |
| IP allowlisting/blocklisting | Allow/deny by IP range or geo | Centralized network access control, one update protects all APIs |
| TLS termination | Handle encryption at the edge | Backend services communicate over internal networks without TLS overhead |
| Logging and auditing | Log every API call with metadata | Single audit trail for all API traffic, feeds into SIEM |
| Bot detection | Identify and block automated abuse | Protect APIs from scraping, credential stuffing, inventory hoarding |
Rate limiting in detail. -backed sliding window counters are the standard. Kong uses Redis with atomic Lua scripts: INCR the key, check against the limit, set EXPIRE if new. This handles 100K+ rate limit checks per second. Configure limits per tier:
/search gets 10/minute (expensive), /status gets 1,000/minute (cheap)The gateway should NOT contain business logic. It handles cross-cutting security concerns. Business authorization ("can this user edit this specific resource?") belongs in the backend service that owns the resource. The gateway answers "is this user authenticated and within their rate limit?" The service answers "does this user have permission to modify document #4521?"
When NOT to use a gateway for internal traffic. For service-to-service communication within a service mesh (Istio, Linkerd), the mesh handles mTLS, retries, and circuit breaking. The protects the external boundary. The mesh protects internal traffic. They are complementary, not redundant.
It is easy and good
“It is really nice and good Please join the course”