"A Graph isn't designed to store objects. It's designed to represent how objects relate to one another."
In the previous article, we explored a different kind of software problem.
Some systems aren't concerned with finding individual objects.
Instead, they need to understand how those objects are connected.
Once you recognize that requirement, another question naturally follows.
How should the system organize those relationships so they can be explored naturally?
This is exactly the problem a Graph solves.
Think About a Metro Map
Imagine looking at a metro network.
You don't see a long list of stations.
Instead, you see stations connected by routes.
Station A
│
├── Station B
│
├── Station C
│
└── Station D
Each station becomes meaningful because of its connections.
Without those connections, the map would simply be a collection of unrelated names.
A Graph works in much the same way.
What Is a Graph?
A Graph is a data structure that represents:
- entities, and
- the relationships between them.
Imagine these users.
Alice
Bob
Charlie
David
If they have no relationships, they're simply four separate records.
Now imagine this.
Alice
│
├── Bob
│
└── Charlie
│
└── David
The connections themselves now become valuable information.
Instead of asking only about users, the application can reason about how users relate to one another.
Every Data Structure Answers a Different Question
By now we've seen several data structures, each solving a different design problem.
A HashMap asks:
Where is this exact object?
A Heap asks:
Which item has the highest priority?
A Queue asks:
Which task should happen next?
A Stack asks:
What is the current working context?
A Trie asks:
What begins with these characters?
A Graph asks:
How are these objects connected?
Choosing the right data structure starts with identifying which business question your software needs to answer.
Relationships Become First-Class Citizens
Imagine a movie recommendation platform.
Suppose a user watches:
Movie A
The application might know:
Movie A
│
├── Similar Genre
├── Same Director
├── Same Actor
└── Frequently Watched Together
The recommendation engine isn't interested only in Movie A.
It explores the relationships surrounding it.
Those relationships drive the recommendations.
Traversing Relationships
Imagine a package delivery network.
Warehouse
↓
Distribution Center
↓
Regional Hub
↓
Delivery Station
To understand how a package reaches its destination, the application follows one connection after another.
The system isn't searching for isolated locations.
It's navigating a connected network.
Why This Behavior Matters
Notice what the system isn't doing.
It isn't asking:
- Where is this object?
- Which object has the highest priority?
- Which object was added most recently?
Instead, it asks:
- What is connected to this object?
- How can I reach another object?
- What relationships exist between them?
Those are fundamentally different questions.
How This Changes Your LLD Design
When designing relationship-heavy systems, avoid embedding relationship logic inside every entity.
Instead, introduce a dedicated component responsible for managing connections.
Business Objects
↓
Relationship Service
↓
Graph
↓
Connected Objects
Business entities focus on their own state.
The relationship service focuses on how those entities interact.
Separating these responsibilities leads to cleaner and more maintainable designs.
Common Beginner Mistakes
Mistake 1 — Thinking Only About Objects
Many applications are driven more by relationships than by the individual objects themselves.
Designing only the entities often misses the real complexity.
Mistake 2 — Treating Relationships Like Simple Fields
Connections are often dynamic.
They can be added, removed, traversed, and analyzed independently of the objects they connect.
Mistake 3 — Modeling Everything as Parent-Child
Not every relationship forms a hierarchy.
Many real-world systems contain multiple interconnected relationships that don't fit neatly into a tree structure.
Mistake 4 — Mixing Relationship Logic With Business Logic
Business entities shouldn't know how to navigate an entire network.
Managing relationships deserves its own responsibility.
Engineering Perspective
Experienced engineers rarely begin with:
"Let's build a Graph."
Instead, they ask:
- Do relationships matter as much as the objects?
- Will users navigate between connected entities?
- Are recommendations or dependency chains important?
- Does the product revolve around a network of connected data?
Once those questions are answered, a Graph often becomes the natural design choice.
The business behavior comes first.
The data structure follows.
The Most Important Insight
A Graph isn't valuable because it connects nodes.
It's valuable because it allows software to model, explore, and reason about relationships.
Whenever relationships become as important as the objects themselves, Graph-based designs become a natural fit.
One-Line Takeaway
A Graph isn't designed for storing isolated objects—it's designed for modeling and navigating the relationships that connect them.
Top comments (0)