DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Data Structures in Design Context: Why Some Problems Are About Relationships, Not Individual Objects

#lld #systemdesign #softwareengineering #codinginterview

"Not every software problem is about finding one object. Sometimes the real challenge is understanding how multiple objects are connected."

So far in this series, we've explored data structures that solve different design problems.

A HashMap helps us find exact objects quickly.

A Heap helps us decide what should happen next.

A Queue helps us process work in order.

A Stack helps us preserve and restore recent context.

A Trie helps us discover values from partial input.

Now let's explore a completely different kind of problem.

Imagine you're building an application where the most important question isn't about an individual object.

Instead, it's about the relationships between many objects.

This is where another fundamental data structure enters the picture—the Graph.

A Simple Example

Think about a navigation application.

Suppose you want to travel from your home to the airport.

The application doesn't simply find two places.

It must understand how those places are connected.

Home

↓

Road A

↓

Road B

↓

Airport
Enter fullscreen mode Exit fullscreen mode

Without understanding the relationships, the destination alone is meaningless.

Another Everyday Example

Imagine using a social networking platform.

You open someone's profile.

Immediately you see:

  • mutual friends,
  • suggested connections,
  • people you may know.

The application isn't interested in a single user.

It's interested in how users are connected.

A Different Kind of Design Problem

Notice how different this is from previous data structures.

A HashMap asks:

Where is this exact object?
Enter fullscreen mode Exit fullscreen mode

A Heap asks:

Which item has the highest priority?
Enter fullscreen mode Exit fullscreen mode

A Queue asks:

Which task should happen next?
Enter fullscreen mode Exit fullscreen mode

A Stack asks:

What is the current working context?
Enter fullscreen mode Exit fullscreen mode

A Trie asks:

What begins with this prefix?
Enter fullscreen mode Exit fullscreen mode

A Graph asks something entirely different.

How are these objects connected?
Enter fullscreen mode Exit fullscreen mode

That's a completely different business requirement.

Why Individual Objects Aren't Enough

Imagine storing cities.

Delhi

Mumbai

Jaipur

Agra
Enter fullscreen mode Exit fullscreen mode

Knowing these cities exist doesn't answer questions like:

  • Can I travel from Delhi to Jaipur?
  • Which route connects Delhi to Mumbai?
  • Are Delhi and Agra directly connected?

The real value lies in the relationships, not the objects themselves.

The Mental Model

Imagine a map.

Delhi

│

├── Jaipur

│

├── Agra

│

└── Chandigarh
Enter fullscreen mode Exit fullscreen mode

Every place is meaningful because of the roads connecting it to other places.

Remove those connections, and you no longer have a network.

You simply have isolated locations.

Graphs capture those connections explicitly.

Recognizing This Kind of Problem

Certain business requirements should immediately make you think about relationships.

Examples include:

  • Route planning
  • Friend recommendations
  • Package delivery networks
  • Flight connections
  • Dependency management
  • Workflow relationships
  • Knowledge graphs

Notice the common pattern.

The application isn't asking about one object.

It's asking about how objects relate to one another.

How This Changes Your LLD Design

When designing such systems, don't immediately ask:

"How should I store these objects?"

Instead ask:

"How are these objects connected?"

That shifts the design significantly.

Business Objects

↓

Relationship Manager

↓

Graph

↓

Connected Objects
Enter fullscreen mode Exit fullscreen mode

Instead of focusing only on entities, the design now gives equal importance to the relationships between them.

Common Beginner Mistakes

Mistake 1 — Thinking Only About Objects

Many systems are driven more by relationships than by the objects themselves.

Ignoring those relationships often leads to poor designs.

Mistake 2 — Treating Relationships as Secondary

In graph-based systems, relationships are often just as important as the entities they connect.

Mistake 3 — Choosing Storage Before Understanding the Problem

The key design question isn't:

"Where should I store these objects?"

It's:

"What kinds of relationships does the business care about?"

Mistake 4 — Assuming Every Connected System Needs a Graph

Simple parent-child structures or one-to-many relationships may not require a Graph.

Choose a Graph when relationships themselves become a core part of the problem.

Engineering Perspective

Experienced engineers don't hear the words "network" or "users" and immediately think "Graph."

Instead, they recognize requirements like:

  • Find connections.
  • Discover relationships.
  • Navigate between entities.
  • Recommend related objects.
  • Traverse a network.

Those are signals that the business revolves around relationships rather than isolated objects.

The Most Important Insight

A Graph isn't designed to store objects.

It's designed to represent how objects are connected.

That's why it powers navigation systems, recommendation engines, dependency management, and countless other applications where relationships matter more than individual entities.

One-Line Takeaway

Great engineers don't choose a Graph because it connects nodes—they choose it when the business revolves around understanding and traversing relationships.

Top comments (0)