Pick the container before you worship the algorithm. This is a field card for common data structures: what they cost, what they are good at, and what their shape looks like when the browser draws the bones.
An array is a shelf: direct index access is easy when you know the slot, but a plain search walks slot by slot until it finds the thing or runs out of shelf.
Ideal use: compact ordered records, numeric buffers, lookup by known index, table-like data, and browser-friendly collections where cache locality matters.
A linked list is a trail of nodes. Insertion is cheap once your hand is on the node, but finding that node usually means following the trail from the head.
Ideal use: queues, LRU internals, undo chains, streaming pipelines, and cases where stable node references beat contiguous storage.
A stack is a pile. You touch the top cheaply, but searching for a buried item means removing or inspecting the pile in order.
Ideal use: recursion, backtracking, parsers, browser history, undo operations, depth-first traversal, and temporary work piles.
A queue is a line at a door. Add to the back, remove from the front, and avoid rummaging unless the job truly needs a search.
Ideal use: task scheduling, event buffers, breadth-first search, printer queues, message passing, and rate-limited workflows.
A deque is a queue with a door at both ends. It is useful when either edge is active, but the middle is still not a magic portal.
Ideal use: sliding windows, work stealing, browser navigation, palindrome checks, and algorithms that need both front and back access.
A hash table turns a key into a bin. Average lookup is fast because the key chooses the neighborhood instead of asking every record in town.
Ideal use: dictionaries, ID-to-record maps, deduplication, membership tests, caches, counters, indexes, and fast joins.
A balanced search tree cuts the remaining search space at each branch. The shape preserves order, so range queries and sorted walks are natural.
Ideal use: ordered maps, range queries, sorted iteration, leaderboards, interval-like retrieval, and data that must stay searchable and ordered.
A heap keeps the most important item at the crown. It is not fully sorted, but it is very good at repeatedly pulling the next priority item.
Ideal use: schedulers, Dijkstra/A* frontiers, top-k results, streaming medians, simulations, and any job with a next-best item.
A graph is not a line, it is a neighborhood map. Traversal cost includes the vertices you visit and the edges you inspect.
Ideal use: ontologies, road networks, citation maps, dependency graphs, social connections, taxonomic relationships, and pathfinding.
A Bloom filter answers “definitely not” or “maybe yes.” It uses several hash marks in a bit field and trades exactness for tiny memory.
Ideal use: preflight duplicate checks, URL crawlers, spell filters, cache guards, large deny/allow lists, and memory-tight screening.
Union-Find tracks which items belong to the same component. Path compression makes repeated finds so close to constant that α(n) is a rounding error in practice.
Ideal use: connected components, Kruskal MST, image segmentation, clustering, island counting, and fast “same group?” questions.
A trie stores strings by shared prefixes. Search cost follows the length of the query, not the total number of stored words.
Ideal use: autocomplete, dictionaries, taxon/name lookup, prefix filters, route matching, token tries, and command palettes.
An LRU cache combines a hash map for instant lookup with a doubly linked list for recency order. Touch an item, move it to the front.
Ideal use: memoization, browser caches, image tiles, API responses, database pages, rendered components, and any bounded hot set.
Use rule: Big O describes growth, not dignity. An O(n) scan over 40 records can beat an elaborate index; the right structure is the one whose shape matches the work.