"A HashMap is fast not because collisions never happen. It is fast because it knows how to handle them efficiently."

In the previous articles, we built the foundation of HashMap thinking.

We understood:

  • Why fast lookup is an important system behaviour.
  • Why unique keys are valuable.
  • How hashing converts keys into predictable locations.

Now let's go one level deeper.

A natural question appears:

"What happens when two different keys produce the same location?"

This is one of the most important concepts behind HashMaps.

Because in the real world, collisions are unavoidable.

Understanding how HashMaps handle them is what separates someone who knows how to use a HashMap from someone who understands how it works.


The Simple View Is Not the Complete Story

Earlier, we represented HashMap like this:

Key

↓

Hash Function

↓

Location

↓

Value

Enter fullscreen mode Exit fullscreen mode

This is a good mental model.

But internally, a HashMap does not have unlimited locations.

It has a fixed number of storage spaces.

These spaces are called:

Buckets

Think of buckets as containers where data can be placed.


Understanding Buckets

Imagine a warehouse.

The warehouse has multiple shelves.

Warehouse

Shelf 1

Shelf 2

Shelf 3

Shelf 4

Enter fullscreen mode Exit fullscreen mode

When a package arrives, a rule decides which shelf it belongs to.

Package ID

↓

Placement Rule

↓

Shelf Number

Enter fullscreen mode Exit fullscreen mode

A HashMap works similarly.

Instead of shelves, it has buckets.

HashMap

Bucket 0

Bucket 1

Bucket 2

Bucket 3

Bucket 4

Enter fullscreen mode Exit fullscreen mode

The hash function decides which bucket should receive a key-value pair.

Example:

User ID

↓

Hash Function

↓

Bucket Number

Enter fullscreen mode Exit fullscreen mode


The Perfect World Does Not Exist

Imagine we have four buckets.

Bucket 0

Bucket 1

Bucket 2

Bucket 3

Enter fullscreen mode Exit fullscreen mode

Now we store users.

User A

↓

Bucket 1


User B

↓

Bucket 3


User C

↓

Bucket 0

Enter fullscreen mode Exit fullscreen mode

Everything looks perfect.

Every user has a separate bucket.

But now another user arrives.

User D

↓

Bucket 1

Enter fullscreen mode Exit fullscreen mode

Wait.

Bucket 1 already contains User A.

What happens now?

This situation is called a:

Collision


What Is a Collision?

A collision happens when multiple keys produce the same bucket location.

Example:

User A

        ↓

    Hash Function

        ↓

    Bucket 1



User D

        ↓

    Hash Function

        ↓

    Bucket 1

Enter fullscreen mode Exit fullscreen mode

Two different users.

Same destination.

This is completely normal.

It does not mean the HashMap is broken.

A good HashMap design expects collisions.


Why Do Collisions Happen?

At first, beginners often think:

"If hashing creates locations, shouldn't every key get a different location?"

The problem is scale.

Imagine:

  • Millions of possible keys.
  • Only thousands of available buckets.

Many different keys will naturally map to the same bucket.

Think about a hotel.

A hotel has limited rooms.

Thousands of people may need accommodation.

Some people will eventually share the same room number on different days.

The limitation is not the people.

The limitation is the number of available rooms.

Similarly:

The limitation is not the keys.

The limitation is the number of buckets.


How Does a HashMap Handle Collisions?

There are different strategies.

The most common approach is:

Store multiple entries inside the same bucket.

Instead of thinking:

Bucket 1

↓

One Value

Enter fullscreen mode Exit fullscreen mode

Think:

Bucket 1

↓

Value A

↓

Value D

↓

Value X

Enter fullscreen mode Exit fullscreen mode

A bucket can contain multiple entries.

When retrieving data, the HashMap does a second-level search inside that bucket.


Two-Level Lookup

This is an important idea.

A HashMap lookup is not always:

Key

↓

Value

Enter fullscreen mode Exit fullscreen mode

Internally, it is closer to:

Key

↓

Hash Function

↓

Bucket

↓

Find Exact Key

↓

Value

Enter fullscreen mode Exit fullscreen mode

The hash function gets us close.

The exact key comparison confirms the correct entry.


Real-World Analogy

Imagine a company directory.

You search for:

Employee Name = Rahul

Enter fullscreen mode Exit fullscreen mode

The company first sends you to:

Department = Engineering

Enter fullscreen mode Exit fullscreen mode

But Engineering has many employees.

Now you search within that department.

Company Directory

↓

Engineering Department

↓

Find Exact Employee

↓

Rahul

Enter fullscreen mode Exit fullscreen mode

The first step reduces the search space.

The second step finds the exact match.

That is how collision handling works.


Why Good Hash Functions Matter

A good hash function tries to distribute keys evenly.

Imagine this situation:

Bucket 0

User A

User B

User C

User D

User E



Bucket 1

Empty



Bucket 2

Empty

Enter fullscreen mode Exit fullscreen mode

One bucket has too much data.

Other buckets remain unused.

This creates slower lookups.

A better distribution looks like:

Bucket 0

User A


Bucket 1

User B


Bucket 2

User C


Bucket 3

User D

Enter fullscreen mode Exit fullscreen mode

The goal is balance.

Spread information evenly.


Real-World Impact

Consider a session management system.

Millions of users are logged in.

Each session is stored using:

Session ID

↓

Session Information

Enter fullscreen mode Exit fullscreen mode

If hashing distributes sessions properly:

Session IDs

↓

Multiple Buckets

↓

Fast Retrieval

Enter fullscreen mode Exit fullscreen mode

The system remains responsive.

If distribution is poor:

Many Sessions

↓

One Bucket

↓

More Searching

↓

Slower Requests

Enter fullscreen mode Exit fullscreen mode

The application performance suffers.


HashMap Performance Depends on Design

People often say:

"HashMap lookup is O(1)."

This is generally true under good conditions.

But the complete story is:

Fast lookup depends on:

  • Good hash function.
  • Good key selection.
  • Reasonable bucket distribution.
  • Efficient collision handling.

A HashMap is not automatically fast.

Its performance depends on how well these pieces work together.


Weak Thinking vs Strong Thinking

Weak Thinking

HashMaps are O(1).

They are always instantly fast.

Enter fullscreen mode Exit fullscreen mode

Strong Thinking

HashMaps are designed for fast lookup.

Their performance depends on good hashing,
balanced distribution and collision handling.

Enter fullscreen mode Exit fullscreen mode


Weak Thinking

Collision means the HashMap failed.

Enter fullscreen mode Exit fullscreen mode

Strong Thinking

Collisions are expected.

A good HashMap is designed to handle them efficiently.

Enter fullscreen mode Exit fullscreen mode


Common Beginner Mistakes

Mistake 1 — Believing collisions should never happen

Collisions are a natural consequence of limited storage locations.


Mistake 2 — Thinking the hash function directly stores data

The hash function only helps determine the bucket.

The actual key-value pair is stored separately.


Mistake 3 — Memorising O(1) without understanding conditions

Complexity depends on assumptions.

Real systems need good design decisions to maintain performance.


Mistake 4 — Ignoring key quality

Poor keys can create poor distribution.

Good system design begins with choosing meaningful identifiers.


Interview Perspective

A common interview follow-up after explaining HashMaps is:

"What happens if two keys have the same hash?"

A weak answer:

"The HashMap breaks."

A stronger answer:

"Different keys can map to the same bucket. The HashMap handles this collision by storing multiple entries in the bucket and comparing the actual keys to find the correct value."

This shows that you understand the internal behaviour.


The Most Important Insight

The power of a HashMap does not come from avoiding collisions.

It comes from reducing unnecessary searching and handling collisions efficiently when they occur.

A good engineer understands both parts:

  • How to reach the right area quickly.
  • How to find the exact information once there.

One-Line Takeaway

A HashMap is fast because hashing gets you close quickly, and collision handling helps you find the exact answer reliably.