📘 Design Patterns for Builders — Part 2 In Part 1, we used Strategy to remove if-else from business logic. Now we fix the next problem: who decides which strategy to create—and how? ⚡ TL;DR Don’t scatter SomeClass() across your codebase Centralize creation behind a factory Separate usage from creation Evolve toward registry/DI as systems grow The Problem (Picking Up From Strategy) After introducing Strategy, you often end up here: ...

You start simple. A small feature. A couple of conditions. Then it grows. And suddenly, your code looks like this: def process_payment(method, amount): if method == "credit_card": return f"Processing {amount} via Credit Card" elif method == "paypal": return f"Processing {amount} via PayPal" elif method == "upi": return f"Processing {amount} via UPI" elif method == "crypto": return f"Processing {amount} via Crypto" else: raise ValueError("Unsupported payment method") Looks fine… until it doesn’t. The Problem At first glance, this works. But the real issue isn’t the if-else. It’s this: ...

Most engineers think support is about “fixing tickets.” It isn’t. Support engineering is a real-time decision system operating under uncertainty, where engineers continuously observe signals, form hypotheses, test them, and take action. This post walks through the actual end-to-end workflow followed by L1, L2, and L3 support engineers in real production systems — with real thinking patterns, not just steps. The Big Picture (High-Level Flow) Every incident flows through a common lifecycle: ...