LLD Data Structures in Design Context: How to Recognize Graph Problems Before Writing Code

"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.