Real World Applications of Algorithms: The DSA You Study Is Already in Production

You're grinding Dijkstra on a Sunday afternoon, questioning every life choice that led you here. You already use it every day. Every time you asked Google Maps for a route, every time Git rejected a corrupted push, every time a JPEG loaded in your browser, you triggered algorithms you're still studying.

Not simplified versions. Not distant cousins. The exact algorithms, running at scale, in systems built by some of the best engineers alive.

Here are five real-world applications of algorithms you're studying, what problem each one actually solves, and why nobody reached for a different tool.

You thought you were studying theory. Turns out you were reading the source code for the internet.

Topological Sort Trains Every Neural Network

A neural network is a directed acyclic graph. Operations are nodes. Tensors are edges. When you call loss.backward(), PyTorch needs to walk this graph in reverse and compute gradients at every node using the chain rule.

The naive approach: just recurse from output to inputs. Fine until a variable fans out and feeds into two or more downstream operations. Reach that variable from one consumer before the other has contributed, and you compute the wrong gradient. Silently. Your model just learns bad weights and you spend three days wondering why your loss curve looks like abstract art.

Topological ordering solves this exactly. Process nodes in reverse topological order: later-in-the-graph nodes first, so by the time you compute a node's gradient, every downstream node has already finished contributing.

This is almost verbatim what Andrej Karpathy's micrograd does, and what PyTorch's C++ engine (torch/csrc/autograd/engine.cpp) does at a larger scale:

def build_topo(node):
    visited, order = set(), []
    def dfs(v):
        if v in visited:
            return
        visited.add(v)
        for parent in v._prev:
            dfs(parent)
        order.append(v)
    dfs(node)
    return order

def backward(loss):
    order = build_topo(loss)
    loss.grad = 1.0
    for node in reversed(order):  # loss node first, leaf nodes last
        node._backward()

PyTorch's C++ version adds a topological_nr_ field to each node: the maximum topological number of all its predecessors. The engine uses a priority queue ordered by this field to schedule work across threads without a coordinator. Topological sort plus a heap. Two algorithms from your LeetCode list, one backward pass.

If you want the full picture of how the topological sort algorithm works, including Kahn's queue-based variant, that post covers both.

Google Maps Runs Dijkstra. Just Not on the Whole Map.

A road network for a country has tens of millions of nodes and edges. Plain Dijkstra takes seconds per query. Google Maps answers in under 100 milliseconds. Something has to give.

The answer is Contraction Hierarchies, developed at the Karlsruhe Institute of Technology. The key insight: road networks have natural hierarchy. Most trips eventually hit a highway. Most highway trips eventually hit a motorway. That residential cul-de-sac is basically irrelevant for anything longer than a trip to the grocery store.

Preprocessing assigns each node an importance score based on how many shortcut edges you'd need if you removed it. You contract nodes in order of increasing importance: remove the least important node, add direct shortcut edges between its neighbors to preserve shortest paths that went through it, repeat. The result is a multi-level hierarchy where motorway interchanges sit at the top.

At query time, you run bidirectional Dijkstra from both source and destination simultaneously, but only traversing edges that go "up" in the hierarchy. The two frontiers meet somewhere near the top, and you reconstruct the path by expanding shortcuts back into real roads.

Speed-up: two to three orders of magnitude over plain Dijkstra. Continental queries in under a millisecond. The answer is still exact, not approximate. The preprocessing took hours once. The payoff is millions of sub-millisecond queries per day.

If you understand Dijkstra's relaxation step and priority queue, Contraction Hierarchies is just that, applied to a cleverly preprocessed graph. Your Sunday LeetCode session was basically infrastructure work.

The assignment felt arbitrary. The database that ran your query three minutes ago did not.

Every SQL Range Query Hits a B+ Tree Three Times

When you run SELECT * FROM orders WHERE created_at BETWEEN '2024-01-01' AND '2024-12-31', PostgreSQL does not scan the table. It walks a B+ tree index.

B+ trees differ from the binary search trees you first learned in one critical way: internal nodes store only keys (no values), and all actual data lives at the leaf level. Every leaf node connects to its neighbors via a doubly linked list in sorted key order.

The branching factor math is what makes this remarkable. PostgreSQL uses 8KB pages. With a 16-byte key and an 8-byte pointer per entry, each internal node holds around 330 entries. Three levels of internal nodes: 330³ is roughly 36 million records reachable in exactly three I/O operations, regardless of table size. Your table can have 36 million rows and you still pay three disk reads to find the start of a range.

The linked leaf layer is the secret weapon for range queries. Find the left boundary in three disk reads. Then walk the linked list sideways until you pass the right boundary. No tree re-traversal. The data comes back in sorted order, which is why your ORDER BY on an indexed column is free.

This is why PostgreSQL, MySQL, SQLite, Oracle, and SQL Server all default to B+ trees for secondary indexes. Every database indexing lecture you sat through was describing a real design decision made by every major database vendor.

Git's Entire History Is a Merkle DAG

Every object Git stores, whether a file, a directory snapshot, or a commit, is identified by the SHA-1 hash of its contents. A blob is the hash of a file. A tree is the hash of a directory listing (which includes the hashes of its blobs and subtrees). A commit is the hash of its metadata plus the hash of the parent commit.

This structure is a Merkle tree with multiple parents per commit node, making it a Merkle DAG. Each node's identity is derived from all its descendants.

Change anything in a commit and its hash changes. The next commit includes the parent hash as part of its input, so its hash changes too. Every subsequent commit in the chain is invalidated. This is why git rebase -i rewriting a commit two weeks back produces entirely new commit IDs for everything after it, and why force-push breaks everyone on the branch. It's not a quirk. It's the structure working exactly as designed.

Content deduplication is free as a side effect. Store the same 50MB file in a hundred commits, and Git keeps one blob. The commit's tree objects just point to the same hash. Repositories that rename files frequently stay lean because content hasn't changed.

Bitcoin uses the same structure. Each block header hashes the previous block's header. Transactions inside a block are arranged in a Merkle tree, and a light client can verify any single transaction with a proof of O(log n) hashes rather than downloading the full block.

Every rewrite rewrites every commit that follows. The hash chain remembers everything.

Every JPEG on the Internet Was Built with a Greedy Priority Queue

JPEG compression moves through three stages: DCT converts spatial pixel data to frequency coefficients, quantization rounds small coefficients to zero, and entropy coding compresses what's left. The entropy coding stage is Huffman, built with the same greedy algorithm you code in interviews.

The algorithm is a textbook greedy problem: given symbol frequencies, build the optimal variable-length prefix code. Always merge the two rarest symbols first.

import heapq
from dataclasses import dataclass, field
from typing import Optional

@dataclass(order=True)
class HuffNode:
    freq: int
    char: Optional[str] = field(compare=False, default=None)
    left: Optional['HuffNode'] = field(compare=False, default=None)
    right: Optional['HuffNode'] = field(compare=False, default=None)

def build_huffman_tree(frequencies: dict[str, int]) -> HuffNode:
    heap = [HuffNode(freq=f, char=c) for c, f in frequencies.items()]
    heapq.heapify(heap)

    while len(heap) > 1:
        left = heapq.heappop(heap)   # rarest symbol
        right = heapq.heappop(heap)  # second rarest
        merged = HuffNode(
            freq=left.freq + right.freq,
            left=left,
            right=right
        )
        heapq.heappush(heap, merged)

    return heap[0]

David Huffman proved in 1952 that this greedy choice is globally optimal: at every step taking the two least-frequent nodes produces the shortest possible total encoded length. O(n log n), one min-heap, provably correct.

DEFLATE (the compression inside ZIP, gzip, and PNG) combines this with LZ77: a first pass finds repeated byte sequences and replaces them with back-references, then a second pass Huffman-codes the result. There's a non-obvious layer here: the two Huffman trees DEFLATE uses are themselves stored as code lengths, which are compressed with a third Huffman code. Turtles all the way down, per RFC 1951.

JPEG does the same analysis per image: scan the DCT coefficient distribution, build an optimal Huffman table for that image's specific statistics, store the table in the file header, then encode. The table and the algorithm are why a 12MB RAW photo becomes a 2MB JPEG with barely visible quality loss.

Knowing the Context Makes the Algorithm Stick

Most interview prep feels detached from real engineering because most resources teach the algorithm without the problem that motivated it. When you know topological sort is what decides whether a neural network gets correct gradients, the traversal order stops feeling arbitrary. When you know B+ tree's linked leaf layer exists because range queries are the primary workload, the design decision sticks long after the interview.

SpaceComplexity runs you through these algorithms in live mock interviews with real follow-up questions: extend your Dijkstra solution for weighted directed graphs, explain what happens when the heap has duplicate distances. Understanding where these algorithms live in production is what separates a rehearsed answer from a convincing one.

---

Further reading

• Contraction Hierarchies (Wikipedia)
• B+ Tree (Wikipedia)
• Merkle Tree (Wikipedia)
• Huffman Coding (GeeksforGeeks)
• DEFLATE Compressed Data Format Specification, RFC 1951