Design

LeetCode 460 note: key → node, freq → doubly linked list, plus a min_freq; within the same frequency, LRU decides what to evict

LeetCode 146 note: a hash map finds nodes and a doubly linked list keeps the usage order; both get and updating an existing key must move the node to the front

LeetCode 449 note: for a BST, pre-order without null markers is enough; deserialize recursively with bounds in O(n)

LeetCode 297 note: pre-order with null markers identifies the tree uniquely; deserialize by consuming tokens from an iterator

LeetCode 173 note: flattening to an array is simple but uses O(n) space; the follow-up keeps the left spine on a stack for amortized O(1) and O(h) space

Point updates with range queries: a Fenwick tree (binary indexed tree) jumps by i & -i, and a segment tree recursively halves the range; both take O(log n) per operation

Circular queues, zigzag iterators, FIFO matching with cancellation, and the data structure combinations that design problems keep using

LeetCode 716 note: store unique ids on both the stack and the heap, record deletions by id, and discard deleted entries lazily; tracking values cannot tell duplicates apart

LeetCode 622 note: a fixed array plus head and count, every position taken modulo the capacity, and count deciding empty versus full

LeetCode 2102 note: two heaps for “top k” and “the rest”, with a custom lt for reversed string order

LeetCode 307 note: point updates with range sums make prefix sums O(n) per update; a segment tree or Fenwick tree makes both operations O(log n)

LeetCode 281 note: a queue of unfinished sources, take one value in turn and put the source back if anything remains; it generalizes to k sources