DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Data Structures in Design Context: Why Software Engineers Think Differently About Data Structures

#lld #systemdesign #softwareengineering #codinginterview

"Learning data structures teaches you how to write efficient programs. Learning Low-Level Design teaches you why those same data structures quietly become the backbone of real software systems."

If you've prepared for coding interviews, you've probably spent weeks—or even months—learning data structures.

Arrays.

Linked Lists.

Stacks.

Queues.

HashMaps.

Heaps.

Trees.

Graphs.

Tries.

You solved hundreds of problems.

You memorised time complexities.

You learned when an operation takes constant time, logarithmic time, or linear time.

Eventually, choosing a data structure for an algorithm became almost second nature.

Then you begin learning Low-Level Design (LLD).

Suddenly, everything feels different.

Instead of solving problems like:

  • Find the first non-repeating character
  • Merge K sorted lists
  • Implement an LRU cache

You're asked to design systems like:

  • Amazon
  • Uber
  • BookMyShow
  • Banking Systems
  • Hospital Management Systems
  • Food Delivery Platforms

The discussion is no longer centred around algorithms.

Instead, it revolves around:

  • Classes
  • Objects
  • Responsibilities
  • Business Rules
  • Entities
  • Services
  • Aggregates
  • Interactions

At this point, many developers naturally wonder:

"Were data structures only useful for DSA? Do they still matter in software design?"

The answer is a resounding yes.

In fact, the larger a software system becomes, the more important data structures become.

The difference is that experienced software engineers think about them very differently.

This article is about understanding that shift.

The Biggest Misconception

Most of us are introduced to data structures through DSA.

As a result, we unconsciously associate them with solving algorithmic problems.

For example, suppose someone asks:

Find a customer by Customer ID.
Enter fullscreen mode Exit fullscreen mode

Your thought process might be:

Need fast lookup
        │
        ▼
Choose an efficient data structure
Enter fullscreen mode Exit fullscreen mode

The goal is simple.

Solve one problem efficiently.

That's exactly what DSA teaches us.

Low-Level Design is different.

Instead of solving one isolated problem, you're designing an entire system.

Imagine designing an online shopping platform.

Customer
     │
Browse Products
     │
Add to Cart
     │
Checkout
     │
Payment
     │
Shipment
Enter fullscreen mode Exit fullscreen mode

Now you're thinking about much bigger questions.

  • What objects exist in this system?
  • How do they collaborate?
  • Which business rules must never break?
  • Which operations happen repeatedly?
  • What should remain fast when millions of users use the application?

Notice how the conversation has changed.

You're no longer focused on a single algorithm.

You're designing an ecosystem of collaborating components.

And that's where data structures quietly become one of the most important engineering tools.

The Same Data Structures. A Completely Different Purpose.

Imagine two developers.

Both have solved hundreds of DSA problems.

Both know exactly what a Stack, Queue, Heap and HashMap are.

Now ask them to design a ride-sharing application.

The first developer immediately says:

Let's use a HashMap.
Enter fullscreen mode Exit fullscreen mode

The second developer asks questions like:

  • How are drivers identified?
  • How do riders search for rides?
  • Which operations happen most frequently?
  • Which actions should feel instant?
  • Which work can happen in the background?
  • What happens when millions of people use the system simultaneously?

Both developers know the same data structures.

Only one starts by understanding the problem.

That's the difference between programming knowledge and engineering thinking.

Experienced engineers rarely begin with tools.

They begin with understanding the system.

Data Structures Don't Build Systems

This statement surprises many beginners.

Data structures don't build systems.

They support system behaviour.

Let's revisit our shopping platform.

At a business level, the workflow looks straightforward.

Browse Products
       │
Add to Cart
       │
Checkout
       │
Payment
       │
Delivery
Enter fullscreen mode Exit fullscreen mode

During Low-Level Design, we identify concepts such as:

  • Customer
  • Product
  • Cart
  • Order
  • Payment
  • Shipment

These become our domain objects.

We define their responsibilities.

We establish business rules.

We model interactions.

So where do data structures fit?

They work behind the scenes, helping the system perform efficiently.

For example:

Customer opens a product page.

↓

System retrieves product information.
Enter fullscreen mode Exit fullscreen mode 
Customer views previous orders.

↓

System finds historical order details.
Enter fullscreen mode Exit fullscreen mode 
Customer begins typing a product name.

↓

System suggests matching products.
Enter fullscreen mode Exit fullscreen mode 
Warehouse receives a new order.

↓

System schedules order processing.
Enter fullscreen mode Exit fullscreen mode

The business never says:

"Please use a Queue."

Or:

"Please implement a HashMap."

The business only describes the behaviour it expects.

It is the software engineer's responsibility to organise information in a way that makes those behaviours efficient.

That's why data structures are design decisions rather than business decisions.

Why Software Engineers Think Differently

Beginners often think of data structures as containers.

For example:

  • A Stack stores data.
  • A Queue stores data.
  • A Graph stores data.

Technically, that's correct.

But experienced engineers think differently.

Instead of asking:

"How should I store this information?"

They ask:

"What behaviour am I trying to optimise?"

That one question changes everything.

Instead of thinking about storage, they think about behaviours like:

  • Finding information instantly.
  • Processing work in order.
  • Selecting the most important task.
  • Exploring relationships.
  • Searching while users type.
  • Reversing previously performed operations.

Software rarely struggles because it cannot store data.

It struggles because users expect the right data to be available immediately.

Different behaviours naturally require different ways of organising information.

That's why different data structures exist.

One Application Uses Many Data Structures

Another common misconception is believing that an application chooses one data structure.

Real software systems don't work that way.

Imagine a food delivery platform.

                 Food Delivery Platform
                          │
      ┌───────────────────┼───────────────────┐
      │                   │                   │
   Products            Orders           Deliveries
      │                   │                   │
Different Behaviour  Different Behaviour Different Behaviour
Enter fullscreen mode Exit fullscreen mode

Every feature has different responsibilities.

Every responsibility has different performance expectations.

Every expectation may require a different engineering solution.

The application isn't built around one data structure.

It's built around many carefully chosen design decisions.

That's why experienced engineers don't ask:

"Which data structure does Amazon use?"

Instead, they ask:

"Which part of Amazon are we talking about?"

Different problems naturally require different solutions.

Weak Thinking vs Strong Thinking

Weak Thinking 

HashMaps are fast.

I'll use one.
Enter fullscreen mode Exit fullscreen mode

Strong Thinking 

Users repeatedly retrieve products using Product IDs.

Fast retrieval is critical for user experience.

The design should optimise that behaviour.
Enter fullscreen mode Exit fullscreen mode

Weak thinking begins with implementation.

Strong thinking begins with understanding.

The implementation follows naturally.

Common Beginner Mistakes

Mistake 1 — Treating data structures as interview topics

Many developers stop thinking about data structures after finishing DSA preparation.

In reality, experienced software engineers rely on them every day while designing systems.

Mistake 2 — Starting with implementation

Choosing a data structure before understanding the problem often leads to unnecessary complexity.

Always understand the system before selecting a solution.

Mistake 3 — Assuming one data structure solves every problem

There is no universally best data structure.

Every one exists because it solves a different engineering problem.

Mistake 4 — Thinking Low-Level Design is only about classes

Classes are only one part of good design.

Efficient systems also depend on choosing the right underlying data organisation.

Interview Perspective

Imagine an interviewer asks:

Design an online movie ticket booking system.

A beginner immediately starts drawing classes.

A stronger candidate pauses and asks questions like:

  • Which operations happen most frequently?
  • What information will users access repeatedly?
  • Which actions must feel instantaneous?
  • What happens when traffic suddenly increases?
  • Which behaviours deserve optimisation?

Notice that none of these questions are about syntax.

They are about understanding the system.

Interviewers often evaluate this thought process more than the final class diagram.

Because mature engineering starts with asking better questions.

The Most Important Insight

Learning DSA teaches you how individual data structures work.

Learning Low-Level Design teaches you why those same data structures become essential building blocks of real software systems.

The data structures haven't changed.

Your perspective has.

And that shift—from solving algorithms to designing systems—is the foundation of becoming a better software engineer.

One-Line Takeaway

A programmer chooses a data structure to solve an algorithm. A software engineer chooses a data structure to support the behaviour of an entire system.

Top comments (0)