We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 8-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 Microservices 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
It is easy and good
“It is really nice and good Please join the course”
An e-commerce team at a mid-sized company noticed their Postgres CPU was pinned at 98% during peak hours. They profiled the queries and found something absurd: the same product catalog query was executing 50,000 times per minute. The catalog changed maybe once a day, but every page load hit the database fresh.
The fix was almost embarrassingly simple. They put a proxy in front of the database. Same interface. getProducts(). But instead of going to Postgres every time, the proxy checked a Redis cache first. Cache hit? Return in 0.3 ms. Cache miss? Query the database, store the result with a 60-second , return it. Database CPU dropped from 98% to 12%. Response times went from 45 ms to under 2 ms for 92% of requests.
That caching is one flavor of the Proxy pattern. But it is not the only one. Proxies show up everywhere in distributed systems, wearing different hats while following the same principle: sit between a client and a real object, add behavior without changing the interface.
The pattern provides a surrogate or placeholder for another object to control access to it. The proxy has the same interface as the real object, so clients cannot tell the difference.
There are five common flavors, each solving a different problem:
| Type | What It Does | Production Example |
|---|---|---|
| Proxy | Stores results and returns cached data for repeated requests | CloudFront , Nginx proxy_cache, database query cache |
| Protection Proxy | Controls access based on permissions | auth check, RBAC middleware |
| Virtual Proxy | Delays expensive object creation until actually needed | Lazy-loaded images, Hibernate lazy associations, on-demand DB pools |
| Logging Proxy | Records all interactions for debugging or auditing | Envoy access logs, AWS CloudTrail |
| Remote Proxy | Represents an object in a different address space | stubs, Java RMI, Kubernetes service proxies |
The key insight: the proxy implements the exact same interface as the real object. Clients call the proxy thinking it is the real thing. The proxy adds its behavior (caching, auth checks, logging) and then optionally forwards to the real object.
Nginx is a caching and load-balancing proxy. Envoy (the sidecar proxy in Istio service meshes) intercepts every connection to and from a pod and adds observability, retries, mTLS, and circuit breaking. CloudFront is a caching proxy that sits between its edge locations and your origin server. AWS's CloudFront features page said, when I checked it on 4 October 2026, "CloudFront has 750+ POPs in 100+ cities across 50+ countries." All of them maintain the same interface the client expects.