Stop Memorizing Trees. Understand Why They Exist.

“Understanding the problem is more valuable than memorizing the solution.”

When I first started learning Data Structures, one question kept bothering me.

Why are there so many different types of trees?

We have Trees.

Then Binary Trees.

Then Binary Search Trees.

Then AVL Trees.

Then Red-Black Trees.

Then B-Trees.

At first, it felt like computer scientists kept inventing new tree structures just to make coding interviews more difficult.

But the truth is completely different.

Every one of these data structures was invented to solve a real-world problem that the previous one couldn’t solve efficiently.

Once I understood that story, I stopped memorizing definitions and started understanding how computer scientists think.

Let’s go back to where it all began.

Chapter 1: The First Problem - Storing Information

Imagine you’re building software for a company.

The company has only five employees.

John
Alice
Bob
David
Emma

The simplest way to store them is inside an array.

[John] [Alice] [Bob] [David] [Emma]

Simple, Easy, Efficient.

Everything seems perfect.

Until someone asks,

“Can you quickly find Emma?”

Your computer starts checking one employee after another.

John ❌
Alice ❌
Bob ❌
David ❌
Emma ✅

In the worst case, it has to check every employee.

If the company has 10 million employees, this becomes painfully slow.

This is called Linear Search, and its time complexity is O(n).

Arrays were excellent for storing information, but they weren’t designed for fast searching.

So engineers started asking a new question.

Can we make searching faster?

Chapter 2: The First Improvement - Sorted Arrays

Someone had a brilliant idea.

Instead of storing data randomly, why not keep everything sorted?

Alice
Bob
David
Emma
John

Now the computer doesn’t need to check every employee.

Instead, it jumps directly to the middle.

If the middle isn’t correct, it eliminates half of the remaining data.

This is Binary Search.

Searching suddenly becomes incredibly fast.

Instead of checking millions of records one by one, the computer keeps cutting the search space in half.

Search complexity improves from:

O(n)

↓

O(log n)

It looked like the problem was solved.

But another problem appeared almost immediately.

Chapter 3: The Hidden Cost

One day, a new employee joins.

His name is Aaron.

Since the array is sorted, Aaron belongs at the very beginning.

Aaron
Alice
Bob
David
Emma
John

To insert Aaron, every existing employee must shift one position.

Alice →
Bob →
David →
Emma →
John →

Searching became fast.

Insertion became slow.

Deleting an employee created exactly the same problem.

Every deletion required shifting elements again.

Engineers had solved one problem and accidentally created another.

Chapter 4 : The Linked List Revolution

Instead of storing everything side by side, what if every employee simply pointed to the next one?

John → Alice → Bob → David → Emma

Now inserting a new employee becomes incredibly simple.

Instead of moving thousands of records, you only change a few pointers.

Insertion becomes almost instantaneous.

This is why linked lists became popular.

Real-world example:

Imagine a train.

Adding another coach doesn’t require moving every existing coach.

You simply connect a new coach between two existing ones.

But…

Searching still requires visiting every node.

To find Emma, the computer still walks through every employee.

John

↓

Alice

↓

Bob

↓

David

↓

Emma

Searching is still O(n).

Once again, one problem was solved while another remained.

Chapter 5: The Bigger Question

At this point, computer scientists asked one of the most important questions in the history of data structures.

Can we build something that supports:

• Fast Searching

• Fast Insertion

• Fast Deletion

That single question eventually led to Trees.

Chapter 6: Why Trees Were Invented

Before talking about searching, let’s understand what a Tree actually solves.

Look around you.

Many things in life aren’t linear.

They are hierarchical.

For example:

Company Structure

CEO
├── Engineering
│   ├── Backend Team
│   └── Frontend Team
├── Marketing
└── Finance

Or your computer’s folders.

Documents
├── College
│   ├── Assignments
│   └── Notes
├── Photos
└── Projects

Or even an online shopping website.

Electronics
├── Laptops
├── Phones
└── Cameras

None of these structures fit naturally into an array.

They have parent-child relationships.

That is exactly what a Tree represents.

A Tree wasn’t invented for faster searching.

It was invented to model hierarchical relationships.

That is why operating systems, HTML documents, XML files, company hierarchies, and file systems all use trees.

Chapter 7: Why Binary Trees Came Next

General trees are flexible.

A node can have any number of children.

CEO
├── HR
├── Sales
├── Finance
├── Marketing
└── Engineering

But many real-world problems naturally have only two choices.

Think about a decision.

Is the user logged in?

Yes

No

Or navigation.

Go Left

Go Right

Or game AI.

Attack

Defend

Or a compiler evaluating an expression.

+
     / \
    *   -
   / \ / \
  3  4 8  2

Binary Trees made these kinds of problems much simpler.

Every node has at most two children:

• Left
• Right

This limitation makes recursive algorithms easier to design and implement.

Binary Trees were created for simplicity, not for faster searching.

Chapter 8: The Birth of Binary Search Trees

Although Binary Trees simplified many algorithms, they still had one major problem.

There was no rule about where values should be stored.

Consider this Binary Tree.

        50
       /  \
     90    20

Where should you go to find 20?

Left?

Right?

There is no way to know.

The computer may need to search almost every node.

Then someone introduced one simple rule.

Everything smaller goes left.

Everything larger goes right.

That single idea created the Binary Search Tree (BST).

          50
        /    \
      30      70
     / \     / \
   20  40  60  80

Now searching becomes intelligent.

Looking for 60?

60 > 50

↓

Go Right

↓

70

↓

60 < 70

↓

Go Left

↓

Found

Instead of searching the entire tree, the computer ignores half of the data at every step.

Searching becomes much faster.

Insertion also becomes efficient.

Deletion becomes efficient.

For the first time, engineers had a structure that handled all three operations well.

Chapter 9: The Plot Twist

Everything looked perfect.

Until someone inserted data in sorted order.

10

20

30

40

50

The Binary Search Tree became this.

10
 \
 20
   \
   30
     \
     40
       \
       50

It wasn’t really a tree anymore.

It had become another linked list.

Searching became slow again.

History repeated itself.

Every solution eventually revealed a new limitation.

Chapter 10: The Next Evolution

Rather than abandoning Binary Search Trees, engineers improved them.

They invented self-balancing trees.

Examples include:

• AVL Trees
• Red-Black Trees
• B-Trees
• B+ Trees

These structures automatically reorganize themselves after insertions and deletions.

That keeps the tree balanced.

A balanced tree remains shallow, allowing searches to stay fast even after millions of operations.

Where Do We Use Them Today?

These data structures quietly power many of the technologies we use every day.

Data Structure Real-world examples Tree File systems, HTML DOM, company organization charts, product categories Binary Tree Expression evaluation, decision trees, game AI, Huffman coding Binary Search Tree Ordered dictionaries, symbol tables, in-memory indexes Red-Black Tree TreeMap and TreeSet in Java, Linux kernel data structures B-Tree / B+ Tree Database indexes (MySQL, PostgreSQL, SQLite), modern file systems

The next time you search for a record in a database or browse folders on your computer, chances are you’re benefiting from one of these tree structures.

The Evolution of an Idea

Arrays
│
├── Searching is slow
│
▼
Sorted Arrays
│
├── Insertion becomes slow
│
▼
Linked Lists
│
├── Searching becomes slow
│
▼
Trees
│
├── Represent hierarchies
│
▼
Binary Trees
│
├── Simplify algorithms with two-child structure
│
▼
Binary Search Trees
│
├── Add ordering for efficient search
│
▼
Balanced Trees
│
├── Prevent worst-case performance
│
▼
B-Trees & B+ Trees
│
└── Optimize searching on disks and databases

Final Thoughts

One of the biggest mistakes beginners make is trying to memorize data structures as isolated topics.

But computer science didn’t evolve that way.

Each new data structure was born because someone encountered a limitation in the previous one.

• Arrays made insertion expensive.
• Linked Lists made searching expensive.
• Trees represented hierarchies.
• Binary Trees simplified processing.
• Binary Search Trees made searching efficient.
• Balanced Trees ensured that efficiency remained consistent as data grew.

Understanding why a data structure exists is far more valuable than memorizing its definition.

Because once you understand the problem, the solution becomes obvious.

And that’s exactly how great software engineers think.

If this article helped you understand trees from first principles, share it with someone who’s currently learning Data Structures. Sometimes, understanding the story behind a concept is far more powerful than memorizing the concept itself.