Handling Constraints & Trade-offs in LLD Interviews

In every LLD interview, there comes a pivotal moment that separates good candidates from exceptional ones. It's not when you write elegant code or correctly apply a design pattern—it's when you pause, look at your design, and say: "There are actually several ways we could approach this. Let me walk you through the alternatives."

This single behavior—proactively discussing design alternatives—signals something profound to interviewers. It demonstrates that you don't view design as a linear path from problem to solution, but as an exploration of a solution space with multiple valid destinations. You understand that real engineering involves choosing among imperfect options, not discovering the one "correct" answer.

The ability to articulate alternatives is what distinguishes a senior engineer from a mid-level one. Junior engineers often solve problems. Senior engineers solve problems and explain why they didn't solve them differently. Staff engineers anticipate which alternative the next requirement change would demand.

Before diving into techniques, let's understand why discussing alternatives is so valuable in an interview context—and in real engineering:

For the interviewer, alternatives demonstrate:

For real-world engineering, alternatives enable:

Systematically identifying alternatives requires structured thinking across multiple dimensions. Use this framework to ensure you've explored the solution space thoroughly:

The SPACE Framework for Alternatives

When facing any design decision, probe these five dimensions:

Applying SPACE: A Concrete Example

Let's say you're designing a notification system for an e-commerce platform. Apply each dimension:

Structure Alternatives:

• Store notification preferences in a simple HashMap per user
• Use a normalized relational model with User, Channel, and Preference entities
• Apply a document model with embedded preferences in the User object

Pattern Alternatives:

• Observer Pattern: Notification service subscribes to order events
• Mediator Pattern: Central NotificationCoordinator routes all messages
• Event Sourcing: Store all notification events and derive current state

Architecture Alternatives:

• Rich Entity: User object knows how to send its own notifications
• Service Layer: Stateless NotificationService acts on passive User objects
• CQRS: Separate NotificationCommandHandler and NotificationQueryService

Complexity Alternatives:

• Simple: Hardcoded notification logic with if-else chains
• Moderate: Strategy pattern for channel-specific sending logic
• Complex: Full plugin architecture for arbitrary notification providers

Extension Point Alternatives:

• Closed: Fixed set of notification channels compiled into the system
• Open: Channel providers discoverable at runtime via registry

Certain types of decisions appear repeatedly in LLD interviews. Mastering the alternatives at these common decision points accelerates your ability to discuss trade-offs fluently.

3.1 Entity Modeling Decisions

3.2 Collection Management Decisions

3.3 Behavioral Variation Decisions

3.4 Object Creation Decisions

Once you've identified alternatives, you need to compare them systematically. The Comparison Matrix is your most powerful tool for this. It transforms vague intuitions into structured analysis.

Building a Comparison Matrix

A comparison matrix has:

• Rows: The alternatives you're comparing
• Columns: The criteria that matter for this decision
• Cells: How each alternative performs on each criterion

Example: Comparing Pricing Strategy Implementations

You're designing an e-commerce pricing system that needs to support multiple pricing strategies (regular, promotional, membership-based).

Interpreting the Matrix

The matrix immediately reveals trade-offs:

• If-Else Chain: Fast to implement, fast to run, but every change requires developer intervention
• Strategy Pattern: Balance of flexibility and simplicity; good for systems where strategies are well-defined but may need updates
• Rule Engine: Maximum flexibility but highest complexity; justified only when business users must define pricing rules without developer involvement

Presenting the Matrix in an Interview

You don't need to literally draw a table in an interview. Instead, structure your verbal comparison:

"Let me compare these three approaches across the dimensions that matter most for this system. For implementation complexity, the if-else approach is simplest, but it becomes a maintenance burden as strategies multiply. The Strategy pattern hits a middle ground—moderate initial investment, but excellent isolation for testing and extension. The rule engine is overkill unless we expect non-technical users to define pricing rules.

"For our stated requirements—developers adding new strategies monthly, no business-user pricing control—I'd recommend the Strategy pattern. It's not the simplest, but it's the most maintainable at our expected scale."

Identifying alternatives is half the battle; presenting them clearly is the other half. Poor presentation can make you seem indecisive or unfocused. Excellent presentation demonstrates confidence and structured thinking.

The Three-Step Presentation Pattern

Step 1: Frame the Decision

Start by naming the decision point explicitly:

"For handling different vehicle types in our parking lot system, we have a design choice to make..."

"The question of how notifications are dispatched could be approached in several ways..."

Step 2: Present Options with Tradeoffs (Not Just Features)

Don't just list options—immediately attach their key trade-off:

"Option A is inheritance-based: VehicleType as abstract class with Car, Motorcycle subclasses. This gives compile-time type safety but means adding new vehicle types requires code changes.

Option B uses composition with a VehicleSpec object containing properties. More flexible for adding types, but we lose some type-safety and IDE support.

Option C is full polymorphism with a Vehicle interface and implementations. Maximum extensibility, but potentially over-engineered if types are stable."

Step 3: State Your Recommendation with Justification

Always end with a clear choice:

"Given that the problem statement mentions we might add boats and bicycles later, Option B gives us the flexibility we need without over-engineering. I'd recommend that approach."

The most effective engineers don't just present alternatives—they use alternative discovery as a collaborative exploration with the interviewer. This transforms the interview from an exam into a design session.

Engaging the Interviewer in Trade-off Discussion

Technique 1: The Clarifying Trade-off Question

After presenting alternatives, ask a targeted question:

"The choice between Strategy and State pattern here depends on how we think about elevator behavior. Do we expect the elevator's rules to change based on what state it's in (like not accepting new requests when at capacity), or is it more about selecting between different dispatching algorithms?"

This invites the interviewer to give hints—and demonstrates that you understand the nuances.

Technique 2: The Requirement Probe

"I see two approaches: a simpler one that's fast to implement but harder to extend, and a more flexible one with upfront cost. Which direction does this system lean—is rapid initial delivery prioritized, or are we optimizing for long-term maintainability?"

Technique 3: The Constraint Surface

"Before I commit to a data structure choice, it would help to know: is memory more constrained than CPU, or vice versa? The HashMap vs. TreeMap choice hinges on whether we're optimizing for lookup speed or memory footprint."

Discussing design alternatives is a core competency that distinguishes senior engineers in LLD interviews. Let's consolidate the key principles:

What's Next:

Presenting alternatives is only the first step. The next page covers Making and Justifying Decisions—how to choose among alternatives, defend your choices under scrutiny, and demonstrate the principled reasoning that defines senior engineering judgment.