It's Monday morning. You're staring at a Jira ticket that reads: "Refactor payment processing to support multiple currencies." The existing system has been in production for three years, handles millions of transactions daily, and was designed before anyone imagined international expansion.

You won't solve this in 45 minutes. You won't even solve it in a week. Over the next several months, you'll study the existing codebase, collaborate with five different teams, navigate conflicting requirements from stakeholders, make incremental changes while keeping production stable, and ultimately deliver a solution that nobody could have designed from scratch.

This is real-world LLD. It's messy, collaborative, iterative, and nothing like an interview. Understanding this reality prepares you for the work that actually awaits you in industry.

In interviews, you design once and never touch it again. In production, design is a continuous activity that spans the entire lifecycle of a system.

Why Iteration Is Necessary:

1. Requirements evolve — Business needs change faster than code can be written
2. Understanding deepens — You learn more about the problem as you implement
3. Constraints emerge — Performance, security, and integration issues reveal themselves
4. Stakeholders clarify — Initial requirements are never complete or consistent
5. Technology changes — Libraries deprecate, patterns evolve, platforms update

The myth of the perfect upfront design is exactly that—a myth. Real engineering is about designing systems that can evolve gracefully.

The Iteration Cycle:

Production design follows a predictable pattern that repeats throughout development:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Understand │────▶│   Design    │────▶│  Implement  │
└─────────────┘     └─────────────┘     └─────────────┘
       ▲                                       │
       │                                       ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Refine    │◀────│   Measure   │◀────│   Deploy    │
└─────────────┘     └─────────────┘     └─────────────┘

Each cycle produces learning that informs the next. The system gets better not through brilliant initial design, but through intelligent response to feedback.

Interview LLD is a solo activity. Real-world LLD is fundamentally collaborative. The quality of your design depends not just on your individual skills, but on how well you work with others.

Stakeholders in Real-World Design:

Every significant design decision involves multiple perspectives:

Design Reviews:

Most organizations formalize collaboration through design reviews. These serve multiple purposes:

1. Knowledge sharing — Spread understanding of system changes across the team
2. Error detection — Fresh eyes catch issues the author missed
3. Alternative exploration — Different perspectives suggest different approaches
4. Documentation — The review process creates written records of decisions
5. Skill development — Junior engineers learn from senior feedback

The Design Document:

Unlike interviews where you think aloud, production design is documented in written form. A typical design document includes:

Interview problems usually present greenfield scenarios: "Design a parking lot system from scratch." Production work is almost never greenfield.

In reality, you inherit codebases with:

• Decisions made by engineers who left years ago
• Patterns that were sensible then but are outdated now
• Undocumented assumptions baked into the design
• Test coverage ranging from comprehensive to nonexistent
• Dependencies on external systems you can't control

The Brownfield Challenge:

Brownfield development—modifying existing systems—requires different skills than greenfield design:

The Strangler Fig Pattern:

One of the most important real-world design patterns is the Strangler Fig—a strategy for replacing legacy systems incrementally:

1. Wrap the legacy system with a facade that provides the interface you want
2. Build new functionality behind the facade using modern design
3. Redirect traffic gradually from legacy to new implementation
4. Remove legacy components once they're no longer used

This pattern lets you improve design over time without the risk of a big-bang rewrite.

Reading Code as a Design Skill:

In brownfield environments, understanding existing code is as important as writing new code. Effective code reading involves:

• Tracing execution paths through the system
• Identifying invariants that the code depends on
• Recognizing patterns (even if poorly implemented)
• Finding extension points where new code can integrate
• Assessing risk of different modification strategies

The interview ends when you finish designing. Production systems live for years or decades. This changes everything about how you should think about design.

The Maintenance Perspective:

In production, the total lifecycle cost of code is dominated by maintenance, not initial development:

This means optimizing for maintainability is more important than optimizing for cleverness.

Design for the Reader:

Code is read far more often than it's written. Real-world design prioritizes:

• Clarity over brevity — Explicit is better than clever
• Consistency over optimality — Predictable patterns reduce cognitive load
• Documentation over comments — Explain the why, not the what
• Simplicity over flexibility — YAGNI (You Aren't Gonna Need It)

Technical Debt as Reality:

Every project accumulates technical debt—design compromises made for expedience that create future maintenance burden. Production LLD requires managing debt explicitly:

• Intentional debt: Known shortcuts taken consciously with a payback plan
• Accidental debt: Problems discovered after the fact
• Debt interest: Ongoing cost of working around suboptimal design
• Debt payment: Refactoring work to improve design quality

The key insight is that some debt is acceptable and even strategic. The skill is knowing how much debt to take and when to pay it down.

Interview LLD rarely touches on production concerns—topics like deployment, monitoring, and operational visibility. In real-world design, these concerns often drive the architecture as much as functional requirements.

Categories of Production Concerns:

Design for Observability:

You can't improve what you can't measure. Production design embeds observability from the start:

// Interview code
public void processPayment(Payment payment) {
    validatePayment(payment);
    chargeCard(payment);
    updateRecord(payment);
}

// Production code
public void processPayment(Payment payment) {
    Span span = tracer.buildSpan("processPayment").start();
    try {
        metrics.counter("payments.attempted").inc();
        
        validatePayment(payment);
        span.log("validation_complete");
        
        chargeCard(payment);
        span.log("charge_complete");
        
        updateRecord(payment);
        
        metrics.counter("payments.succeeded").inc();
        span.setTag("result", "success");
    } catch (Exception e) {
        metrics.counter("payments.failed").inc();
        span.setTag("error", true);
        span.log("error: " + e.getMessage());
        throw e;
    } finally {
        span.finish();
    }
}

The production code is longer and more complex—but it's engineered for visibility. When something goes wrong at 3 AM, you'll thank past-you for the telemetry.

In interviews, feedback comes from the interviewer's hints and expressions. In production, feedback comes from multiple channels, each revealing different aspects of your design's quality.

Production Feedback Channels:

Learning from Incidents:

Production incidents are the most valuable (and painful) source of design feedback. A mature engineering culture conducts blameless post-mortems that ask:

• What design decisions contributed to this failure?
• What observability gaps prevented faster detection?
• What would make the system more resilient to similar issues?
• What changes would prevent recurrence?

These insights feed directly back into design improvements. The best production engineers actively seek this feedback rather than avoiding it.

Continuous Improvement:

Real-world LLD isn't a one-time activity—it's an ongoing dialogue between design and reality. Every deployment teaches you something. Every incident reveals an assumption. Every code review shares perspective.

The engineer who designs the best systems isn't necessarily the smartest at initial design. They're the ones who learn fastest from feedback and improve most relentlessly.

Interview LLD typically focuses on core business logic. Production LLD must also address cross-cutting concerns—aspects that affect multiple components and don't fit neatly into a single class.

Common Cross-Cutting Concerns:

1. Logging and Tracing — How do we track execution across components?
2. Authentication/Authorization — How do we verify identity and permissions?
3. Error Handling — How do we deal with failures consistently?
4. Configuration — How do we vary behavior across environments?
5. Caching — Where do we cache, and how do we invalidate?
6. Transaction Management — How do we ensure data consistency?
7. Internationalization — How do we support multiple languages/regions?
8. Auditing — How do we track who did what and when?

Design Patterns for Cross-Cutting Concerns:

Managing these concerns cleanly requires specific patterns that interview LLD rarely covers:

Example: Consistent Error Handling Architecture

Without a cross-cutting strategy, every component invents its own error handling:

// Inconsistent - each class does its own thing
class OrderService {
    void placeOrder() {
        try { ... }
        catch (Exception e) {
            log.error("Order failed", e);
            throw new RuntimeException(e);  // Lost context!
        }
    }
}

class PaymentService {
    void processPayment() {
        try { ... }
        catch (Exception e) {
            e.printStackTrace();  // Goes nowhere in production!
            return null;  // Silent failure!
        }
    }
}

With a cross-cutting architecture, behavior is consistent and centralized:

// Consistent - error handling is standardized
abstract class DomainException extends RuntimeException {
    abstract ErrorCode getCode();
    abstract Map<String, Object> getContext();
}

class OrderServiceException extends DomainException { ... }
class PaymentServiceException extends DomainException { ... }

// Global error handler (in middleware/interceptor)
class GlobalErrorHandler {
    void handle(DomainException e) {
        logger.error("Domain error", 
            "code", e.getCode(),
            "context", e.getContext());
        metrics.counter("errors." + e.getCode()).inc();
        alertIfCritical(e);
    }
}

This architecture ensures every error gets logged, measured, and potentially alerted—without individual services reimplementing the wheel.

Real-world LLD is a fundamentally different discipline than interview LLD. Where interviews reward quick thinking and elegant initial designs, production rewards sustainable evolution, team collaboration, and maintenance awareness.

What's Next:

Now that we understand both interview and real-world contexts, we'll examine what interviewers actually expect—the specific signals they look for and how to demonstrate competency within interview constraints while building skills that transfer to production work.