Proxy
Description
A proxy is a stand-in that preserves the subject’s interface but interposes itself between client and subject. From the client’s perspective the proxy is indistinguishable from the subject — same calls, same return shapes — but the proxy gets to do something on the way through: check permissions, cache results, lazy-instantiate the real subject, log accesses, throttle, encrypt, marshal to a remote process.
The defining contrast is with adapter: an adapter changes the interface shape, a proxy preserves it. The defining contrast with decorator is orientation: a decorator adds behavior to operations; a proxy controls access to operations.
Triggers
User-initiated: User describes wanting to add caching, access control, logging, or remoting without changing the surface the rest of the code calls. Vocabulary cues: “transparent,” “intercept,” “on the way through,” “without the caller noticing,” “stand-in.”
Agent-initiated: Agent notices that some cross-cutting concern (auth, logging, caching, rate-limiting, remoting) is being repeatedly tangled into call sites and would be better absorbed at a single interception point. Candidate inference: “introduce a proxy in front of the subject; pull the cross-cutting concern out of the call-site noise.”
Situation-shape signals: Repeated boilerplate around access to a single resource. A subject that’s expensive to construct but cheap to wrap. A boundary between two trust domains where access deserves checking. A subject that needs to be reachable from another process / machine.
Exclusions
- No cross-cutting concern to absorb — if every call site has its own bespoke pre/post logic, there’s nothing for the proxy to factor out; adding a proxy is then overhead without reuse.
- The control is semantic, not structural — if “controlling access” means changing what the operation means (different return values, different effects), it’s not a proxy anymore; it’s an alternate implementation pretending to be a proxy, which leaks badly.
- Performance budget can’t afford the indirection — tight loops and hot paths sometimes can’t tolerate even a virtual-method-call layer; the proxy must be inlined or omitted.
Relationships
- active-gate-vs-passive-audit — the protection-proxy variant is exactly active-gate; the proxy blocks before passing through, vs. audit that records and surfaces later.
- surface — the proxy is the surface the client sees; the subject is what’s behind the surface, possibly with structural detail the client never needs to see.
- adapter — proxy and adapter are siblings at the interface boundary; proxy preserves the shape, adapter changes it.
- decorator — proxy and decorator share the wrap-the-subject shell but differ in intent: control vs. extend.
- cost-cascade — caching proxies are the canonical cheap-default → expensive-fallback case; the proxy serves from cache and only falls through to the subject on miss.
Examples
HTTP forward / reverse proxies
Domain: computer-science
caching, request filtering, TLS termination; the canonical network case.
Legal proxy (power of attorney; proxy voting) — predates software; the structural shape is “stand-in authorized to act in subject’s place”
Domain: law
cross-domain reach into law/governance reinforces this as a primitive, not a software-specific pattern
CPU cache
Domain: computer-science
hardware proxy that intercepts memory accesses and serves them from a faster tier when possible.
Gamma, Helm, Johnson, Vlissides (1994), Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four). Structural pattern, ch. 4.
Domain: computer-science
The Gang of Four’s Design Patterns (1994) gave the canonical object-oriented articulation of Proxy as a structural pattern. A proxy object implements the same interface as a real subject and forwards calls to it, but interposes additional behavior at the call site. The book enumerates four named variants — virtual proxy (defer expensive subject creation), remote proxy (represent an object in another address space), protection proxy (enforce access control), smart reference (add reference counting, locking, or other bookkeeping) — all of which collapse to the same control-the-access structural shape.
The pattern itself was older than the GoF naming; the same shape had existed under many other names — stub, surrogate, placeholder, ambassador — across distributed systems, remote-method-invocation frameworks, and operating-system kernels. The book’s contribution was less invention than naming-and-stabilization: once Proxy had a catalog entry next to Adapter and Decorator, designers could discuss which pattern fit a problem without arguing about vocabulary.
Inference: The interface-preservation property is constitutive. A proxy must be indistinguishable from the real subject at the call site, or it stops being a proxy and becomes an adapter (different interface) or a decorator (added behavior visible at the interface). The catalog’s neighbors adapter and decorator are where the contrast lives.
GoF protection proxy
Domain: computer-science
enforces access control before delegating to the subject.
GoF remote proxy
Domain: computer-science
local stand-in for an object that actually lives on another machine; marshals calls across the network.
GoF smart proxy / smart pointer
Domain: computer-science
wraps a raw pointer and adds reference counting, locking, or other lifecycle management.
GoF virtual proxy
Domain: computer-science
defers creating the real subject until first access (lazy load).
Service mesh sidecar (Envoy, Istio)
Domain: computer-science
transparent network proxy injected next to each service.