System Design ( Day - 57 )

Proxy Design Pattern

Definition
The Proxy pattern provides a surrogate or placeholder for another object to control access to it.

Types
1. Virtual Proxy
2. Protection Proxy
3. Remote Proxy

📦 1. Virtual Proxy

1. Use Case: Lazy-load a heavyweight resource only when it’s actually needed.

   • Problem: Loading a high-resolution image or large file into memory upfront slows down startup.

   • Solution: VirtualProxy holds minimal metadata (e.g. file path). On display(), it loads the real image and then forwards the call.

   • Benefit: Defers expensive initialization until the very moment of first use.

🔐 2. Protection (Access) Proxy

Use Case: Enforce security or permission checks before allowing method calls.

• Problem: Certain operations (e.g. unlocking a PDF, modifying data) should be restricted to privileged users.

• Solution: ProtectionProxy checks user credentials or roles; only if they pass, it delegates to the real object. Otherwise, it rejects or throws an exception.

• Benefit: Centralizes access control logic and keeps the real object clean of security code.

🌐 3. Remote Proxy

Use Case: Represent an object that lives in a different address space (e.g. across the network) as if it were local.

• Problem: You want to call methods on a service running on another server but hide all the networking details.

• Solution: RemoteProxy implements the same interface, but under the hood it marshals requests, sends them over RPC/HTTP, and unmarshals responses.

• Benefit: Clients remain blissfully unaware of latency, serialization, or network errors—they just call fetchData().

🌟 When to Use Proxy?

• Lazy Initialization: Delay costly creation (Virtual).

• Security: Guard sensitive operations (Protection).

• Remote Access: Wrap network communication (Remote).

• Logging/Caching: Add cross-cutting concerns without polluting business logic.