"Experienced engineers don't recognize a Graph because someone mentions a network. They recognize it because the business revolves around exploring relationships."
So far in this Graph mini-series, we've learned:
- why some software problems are driven by relationships instead of individual objects,
- how a Graph organizes connected entities,
- and why it naturally supports traversing those relationships.
But understanding a Graph isn't enough.
The real engineering skill is recognizing when a business requirement naturally calls for relationship-based modeling.
Let's learn how to identify those situations.
Start With the Business, Not the Data Structure
Imagine you're asked to design a recommendation feature for a video streaming platform.
A beginner might immediately think:
Should I use
HashMap?
Database?
Graph?
An experienced engineer starts differently.
They first ask:
"What relationships does the business care about?"
The relationships determine the design.
Question 1: Is the Relationship More Valuable Than the Object?
Imagine these requirements.
- Recommend similar movies.
- Show mutual friends.
- Find package delivery routes.
- Display service dependencies.
What's common across all of them?
Objects
↓
Relationships
↓
Business Value
The business isn't asking only about individual objects.
It's asking about how those objects relate to one another.
That's the strongest signal for considering a Graph.
Question 2: Will the System Move From One Object to Another?
Imagine a navigation application.
Home
↓
Metro Station
↓
Airport
↓
Hotel
The application isn't interested only in the destination.
It must travel through intermediate connections.
Whenever software repeatedly moves from one connected object to another, Graph thinking becomes valuable.
Question 3: Can an Object Have Many Different Relationships?
Imagine a movie.
Movie
│
├── Actor
├── Director
├── Genre
├── Language
└── Similar Movies
One object participates in many different kinds of relationships.
When relationships become rich and interconnected, a Graph often models them more naturally than simple hierarchical structures.
A Simple Recognition Framework
Whenever you're unsure, ask these questions.
Does the business care about relationships?
↓
Yes
↓
Will software navigate those relationships?
↓
Yes
↓
Can objects have multiple connections?
↓
Yes
↓
Consider a Graph
Notice where the process begins.
Not with implementation.
It begins with business behavior.
Example: Social Network
Imagine these users.
Alice
Bob
Charlie
David
Now suppose the business asks:
- Who are Alice's friends?
- Which friends do Alice and Bob have in common?
- Who might Alice know?
- Can Alice reach David through existing connections?
These questions aren't about individual users.
They're about exploring the relationships between users.
That's classic Graph behavior.
Recognize Behaviors, Not Applications
Many beginners memorize examples.
- Navigation apps use Graphs.
- Social networks use Graphs.
- Recommendation engines use Graphs.
Experienced engineers think differently.
They recognize recurring behaviors like:
- Relationship traversal
- Path discovery
- Dependency analysis
- Connected recommendations
- Network exploration
These behaviors appear across many different industries.
The products change.
The underlying design problem remains the same.
Clues That Often Suggest a Graph
Whenever requirements include ideas like these, pause and think.
Recommendations
Mutual Connections
Dependencies
Routes
Connected Objects
Relationship Network
Path Discovery
Network Traversal
These aren't guarantees.
They're simply strong signals that the feature may naturally benefit from Graph-based modeling.
How This Changes Your LLD Design
Avoid letting every business service manage relationships independently.
Instead, introduce a dedicated relationship component.
Business Objects
↓
Relationship Service
↓
Graph
↓
Connected Results
Business services remain responsible for business rules.
The relationship service specializes in managing and traversing connections.
This separation keeps the architecture cleaner and easier to evolve.
Common Beginner Mistakes
Mistake 1 — Choosing a Graph Because Objects Are Connected
Almost every application contains relationships.
A Graph becomes valuable only when navigating those relationships is central to the business.
Mistake 2 — Thinking Only About Objects
Many systems derive their real value from the relationships between entities, not the entities alone.
Mistake 3 — Memorizing Applications Instead of Behaviors
Don't remember that social networks use Graphs.
Remember that exploring connected relationships naturally leads to Graph behavior.
Mistake 4 — Mixing Relationship Logic With Business Logic
Managing relationships deserves its own responsibility.
Keeping traversal logic inside a dedicated component produces cleaner, more maintainable designs.
Engineering Perspective
During design discussions, experienced engineers rarely ask:
"Should we use a Graph?"
Instead, they ask:
- Does the business revolve around relationships?
- Will users navigate connected data?
- Are recommendations or dependencies important?
- Do we need to discover paths between objects?
The answers naturally reveal whether a Graph belongs in the design.
The business behavior always comes first.
The Most Important Insight
The strongest signal for using a Graph isn't that you're building a social network.
It's that the business must understand, navigate, and reason about relationships between objects.
Once you recognize that behavior, Graph problems become much easier to identify.
One-Line Takeaway
Don't choose a Graph because you've seen it in navigation apps—choose it when the business revolves around exploring connected relationships.
Top comments (0)