LLD Mastery: The Strategy Design Pattern

1. What is the Strategy Pattern?

The Strategy Pattern is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

This is the ultimate weapon against the "If-Else Nightmare." When you have a class that does something in multiple different ways (e.g., calculating shipping costs for Standard, Express, or Same-Day), embedding that logic inside a single method violates the Single Responsibility Principle (SRP) and the Open/Closed Principle (OCP).

2. The Core Problem: The "If-Else" Nightmare

Imagine you are building a Payment Processing engine.

public class PaymentService {
    public void processPayment(String method, double amount) {
        if (method.equals("CREDIT_CARD")) {
            // 50 lines of Credit Card logic
            System.out.println("Processing " + amount + " via Credit Card");
        } else if (method.equals("PAYPAL")) {
            // 50 lines of PayPal logic
            System.out.println("Processing " + amount + " via PayPal");
        } else if (method.equals("CRYPTO")) {
            // 50 lines of Crypto logic
            System.out.println("Processing " + amount + " via Crypto");
        }
        // Every new payment method requires modifying this file!
    }
}

3. The Solution: Interchangeable Algorithms

We define a common interface for all algorithms and let the "Context" (the app) choose which one to use at runtime.

Step 1: The Strategy Interface

public interface PaymentStrategy {
    void pay(double amount);
}

Step 2: Concrete Strategies

public class CreditCardStrategy implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Processing " + amount + " via Credit Card API");
    }
}

public class PayPalStrategy implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Processing " + amount + " via PayPal API");
    }
}

Step 3: The Context

public class PaymentContext {
    private PaymentStrategy strategy;

    // The strategy is injected at runtime
    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void executePayment(double amount) {
        if (strategy == null) throw new IllegalStateException("Strategy not set");
        strategy.pay(amount);
    }
}

4. Real-world Intuition: The Route Planner

Think of Google Maps. You want to get from A to B. The "Context" is the mapping app. The "Strategies" are the different modes of transport: Driving, Walking, Biking, or Public Transit. The app simply calls routeStrategy.buildRoute(A, B). It doesn't care how the route is built; it just delegates the work to the specific algorithm you selected.

5. The "Staff" Perspective on Strategy

In modern Spring Boot applications, the Strategy pattern is often implemented using a Map of beans. Instead of a setPaymentStrategy method, you inject all implementations into a Map where the key is the strategy name.

@Service
public class PaymentService {
    private final Map<String, PaymentStrategy> strategies;

    @Autowired
    public PaymentService(Map<String, PaymentStrategy> strategies) {
        // Spring automatically injects all beans implementing PaymentStrategy
        // where the map key is the bean name.
        this.strategies = strategies;
    }

    public void pay(String method, double amount) {
        PaymentStrategy strategy = strategies.get(method);
        strategy.pay(amount);
    }
}

This entirely eliminates the need for Factory switch statements or manual context setting.

6. Interview Verbal Script

Interviewer: "When would you choose Strategy over inheritance (Template Method)?"

You: "I strongly prefer the Strategy Pattern (composition) over the Template Method (inheritance) because it provides flexibility at runtime. With inheritance, the algorithm is statically bound at compile-time. If a User class inherits from PremiumUser, it cannot easily switch to StandardUser logic later. By using Strategy, I encapsulate the behavior into a separate object, allowing the context class to swap algorithms dynamically on the fly. Furthermore, it prevents the 'fragile base class' problem, where changes to a superclass inadvertently break child classes."

Advanced Architectural Blueprint: The Staff Perspective

In modern high-scale engineering, the primary differentiator between a Senior and a Staff Engineer is the ability to see beyond the local code and understand the Global System Impact. This section provides the exhaustive architectural context required to operate this component at a "MANG" (Meta, Amazon, Netflix, Google) scale.

1. High-Availability and Disaster Recovery (DR)

Every component in a production system must be designed for failure. If this component resides in a single availability zone, it is a liability.

• Multi-Region Active-Active: To achieve "Five Nines" (99.999%) availability, we replicate state across geographical regions using asynchronous replication or global consensus (Paxos/Raft).
• Chaos Engineering: We regularly inject "latency spikes" and "node kills" using tools like Chaos Mesh to ensure the system gracefully degrades without a total outage.

2. The Data Integrity Pillar (Consistency Models)

When managing state, we must choose our position on the CAP theorem spectrum.

3. Observability and "Day 2" Operations

Writing the code is only 10% of the lifecycle. The remaining 90% is spent monitoring and maintaining it.

• Tracing (OpenTelemetry): We use distributed tracing to map the request flow. This is critical when a P99 latency spike occurs in a mesh of 100+ microservices.
• Structured Logging: We avoid unstructured text. Every log line is a JSON object containing correlationId, tenantId, and latencyMs.
• Custom Metrics: We export business-level metrics (e.g., "Orders processed per second") to Prometheus to set up intelligent alerting with PagerDuty.

4. Production Readiness Checklist for Staff Engineers

• Capacity Planning: Have we performed load testing to find the "Breaking Point" of the service?
• Security Hardening: Is all communication encrypted using mTLS (Mutual TLS)?
• Backpressure Propagation: Does the service correctly return HTTP 429 or 503 when its internal thread pools are saturated?
• Idempotency: Can the same request be retried 10 times without side effects? (Critical for Payment systems).

Critical Interview Reflection

When an interviewer asks "How would you improve this?", they are looking for your ability to identify Bottlenecks. Focus on the network I/O, the database locking strategy, or the memory allocation patterns of the JVM. Explain the trade-offs between "Throughput" and "Latency." A Staff Engineer knows that you can never have both at their theoretical maximums.

Optimization Summary:

1. Reduce Context Switching: Use non-blocking I/O (Netty/Project Loom).
2. Minimize GC Pressure: Prefer primitive specialized collections over standard Generics.
3. Data Sharding: Use Consistent Hashing to avoid "Hot Shards."

Read Next

• LLD Mastery: The Factory Pattern
• Case Study: Design a Parking Lot System