Back to topics
LL

Linked List in the real world

Linked lists trade random access for flexible rewiring. They appear in low-level systems where objects are constantly added, removed, or moved without shifting large contiguous blocks of memory.

pointer rewiringstable local updatescheap middle insert/delete

Why it shows up

Teams reach for linked lists when structural updates are more frequent than indexed reads and node references are already available.

Choose it when O(1) splicing matters more than cache locality, especially in kernels, memory managers, and cache eviction logic.

Common domains

OS kernelsmemory allocatorsLRU caches
01

Process queues, timer lists, device lists, and wait queues

Operating system kernels

Kernel subsystems constantly splice tasks and devices in or out of internal lists while the machine is running. Linux-style intrusive lists are a classic example.

Why this structure fits

The kernel often already owns the node pointer, so removal or movement can happen without shifting memory.

02

Free lists for available memory blocks

Memory allocators

Allocators maintain chains of free blocks and rewire them as memory is split, merged, allocated, and returned.

Why this structure fits

The allocator cares about fast structural updates more than direct indexing.

03

Hash map + doubly linked list

LRU cache internals

Many LRU cache designs use a hash map for lookup and a doubly linked list to move recently used items to the front and evict the oldest item from the tail.

Why this structure fits

The linked list gives constant-time reorder and eviction once the cache entry is found.

04

Editors, design tools, and browsing history

Undo and redo timelines

Doubly linked structures are a natural fit for stepping backward and forward through a sequence of user states.

Why this structure fits

Bidirectional traversal matters more than fast random access.