Composing Data Structures Into One System

Across nine modules and eight lab levels, this tier built a stack, a circular-buffer queue, a hashmap, a linked list, a rotated-array binary search, a memoized recursive function, and a min-heap, plus a set of two-pointer and sliding-window array techniques. Each one exists because it answers one question especially well. Real software rarely needs just one of those questions answered. It usually needs several, at once, working together.

• -Stack: "what happened most recently?" LIFO order, used for undo history, matching brackets, and depth-first search.
• -Queue (circular buffer): "what arrived first?" FIFO order with O(1) at both ends, used for task scheduling and breadth-first search.
• -HashMap: "does this exact key exist, and what is attached to it?" average-case O(1) lookup via hashing and chaining.
• -Linked List: "how do I insert or remove cheaply without shifting everything?" O(1) at the ends, at the cost of random access.
• -Binary Search: "where is this, in sorted or rotated-sorted data?" O(log n) by halving the search space each step.
• -Recursion & Memoization: "how do I avoid recomputing the same subproblem?" caching turns exponential branching into linear work.
• -Heap: "what is currently smallest or largest, right now, as things change?" O(log n) insert and remove, O(1) peek.
• -Two Pointers & Sliding Window: "can this be answered over a sorted array or contiguous range without a nested loop?" O(n) instead of O(n²).

An LRU (least-recently-used) cache is a favorite concrete example precisely because it needs two of the structures above at once: a hashmap for O(1) "does this key exist, and where," and a linked list (specifically doubly-linked, a small step past what was built in this tier) to track access order so the least-recently-used entry can be evicted in O(1) as well. Neither structure alone gets there, but together they do. A task scheduler might combine a heap (what is the next highest-priority job) with a hashmap (look up a job's current status by id) and a queue (a fair FIFO fallback for jobs sharing the same priority). A rate limiter might combine a queue of recent request timestamps with the same arithmetic used in this tier's sliding-window chapter.

This toy version's self._order.pop(0) call is the exact same O(n) shift flagged back in the stacks-and-queues module. A production version would swap it for the circular buffer built in that module, or more commonly a doubly-linked list, to get true O(1) eviction. The point is not the toy code itself, but the shape: identify what question the system actually needs answered, then pick the structure from this tier built specifically to answer it fast.