DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Data Structures in Design Context: Choosing the Right Data Structure Starts With the Business Problem

#lld #systemdesign #softwareengineering #codinginterview

"Experienced engineers don't start with data structures. They start with business behavior."

Throughout this series, we've explored several fundamental data structures.

But the biggest lesson isn't how a HashMap works or when to use a Queue.

The biggest lesson is this:

The right data structure is rarely chosen because of its implementation. It's chosen because of the problem the business needs to solve.

Let's bring everything together.

A Common Beginner Approach

Imagine you're asked to design a new feature.

Many beginners immediately think:

Should I use

HashMap?

Queue?

Graph?

Trie?
Enter fullscreen mode Exit fullscreen mode

The conversation starts with implementation.

But that's the wrong place to begin.

The Experienced Engineer's Approach

Experienced engineers ask different questions.

What problem is the business solving?

↓

What behavior does the system need?

↓

Which data structure naturally supports that behavior?
Enter fullscreen mode Exit fullscreen mode

The implementation comes last.

Every Data Structure Answers a Different Question

Let's revisit the journey.

HashMap

Business Question

How do I quickly find this exact object?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

HashMap
Enter fullscreen mode Exit fullscreen mode

Heap

Business Question

Which item should be handled first?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

Heap
Enter fullscreen mode Exit fullscreen mode

Queue

Business Question

What should be processed next in arrival order?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

Queue
Enter fullscreen mode Exit fullscreen mode

Stack

Business Question

How do I preserve and restore recent context?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

Stack
Enter fullscreen mode Exit fullscreen mode

Trie

Business Question

How do users discover values from partial input?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

Trie
Enter fullscreen mode Exit fullscreen mode

Graph

Business Question

How are objects connected?

How do I navigate those relationships?
Enter fullscreen mode Exit fullscreen mode

Natural Choice

Graph
Enter fullscreen mode Exit fullscreen mode

Notice the Pattern

Every design decision follows the same sequence.

Business Requirement

↓

System Behavior

↓

Data Structure

↓

Clean Design
Enter fullscreen mode Exit fullscreen mode

Not the other way around.

The Wrong Question

Many design discussions begin like this.

"Should we use a Graph?"

Or:

"Can we solve this using a Queue?"

Those questions skip the most important step.

The Better Question

Instead ask:

  • What problem are users trying to solve?
  • What behavior does the business expect?
  • What responsibility should this component have?
  • Which data structure naturally supports that behavior?

Now the design becomes much easier.

How This Changes Your LLD Design

When designing a new component, resist the temptation to choose a familiar data structure first.

Instead, identify the responsibility.

Business Requirement

↓

Component Responsibility

↓

Behavior

↓

Data Structure
Enter fullscreen mode Exit fullscreen mode

A well-designed component doesn't use a data structure because it's popular.

It uses one because it fits the behavior it must support.

Common Beginner Mistakes

Mistake 1 — Choosing a Favorite Data Structure

Every data structure has strengths and trade-offs.

The business problem should decide which one belongs in the design.

Mistake 2 — Thinking in Terms of Implementation

Implementation details matter.

But they come after understanding the business behavior.

Mistake 3 — Memorizing Use Cases

Don't memorize:

  • HashMap for caching
  • Queue for messaging
  • Graph for navigation

Instead, recognize the behaviors that naturally lead to those choices.

Mistake 4 — Ignoring Responsibilities

The same application may use multiple data structures.

Each component should choose the one that best supports its own responsibility.

Engineering Perspective

One of the biggest differences between beginner and experienced engineers is where they start.

Beginners ask:

"Which data structure should I use?"

Experienced engineers ask:

"What behavior am I trying to model?"

Once that question is answered, the appropriate data structure often becomes obvious.

The Most Important Insight

Data structures aren't independent design decisions.

They are consequences of understanding the business problem correctly.

When the behavior is clear, the implementation usually follows naturally.

One-Line Takeaway

Great engineers don't begin with data structures—they begin with business behavior, and let that behavior guide every design decision.

Top comments (1)

Collapse
 
swapnoneel123 profile image
Swapnoneel Saha •

starting from business behavior is the right habit. i would add one step between the business question and the data structure, write down the access pattern and the main invariant. include read and write frequency, size limits, ordering needs, and failure behavior. then a small workload table can show why a choice fits and when it should change. this turns a good rule into a repeatable design review.