Skip to content
academia.sh
tr
Log in

Course Intermediate

In-Memory Stores and Caching Systems

By the end of this course

Start course

01

Data Structures and Commands

Mapping the structures an in-memory store offers to scenarios: key setting, reading, and expiration, counters built on atomic increment, lists as queues and stacks, hash structures that manage object fields separately, sets and sorted sets in membership and ranking scenarios, bitmaps and probabilistic structures for memory-efficient counting, streams and consumer groups as an ordered event log, spatial indexes for location-based queries, and server-side scripting for atomic multi-step operations.

  1. 01 Key-Value Basics The contract and the cost of an in-memory store: building set, get, and expiration on a hand-written store, counting bytes held per entry as key, value, and overhead, comparing no-expiration, fixed-expiration, and sliding-expiration policies on peak memory and re-entry count, the effect of key and value shape on bytes held, and how overhead scales with entry count.
  2. 02 Strings and Counters What atomic increment buys: updating the same loan counter with read-modify-write and with the store's own single-step increment, measuring the lost updates and round trips this produces at increasing branch concurrency, breaking down a counter's real memory price into key, value, and overhead, and comparing no-counter, partial-counter, and full-counter options in terms of steps prevented per byte.
  3. 03 Lists The cost of holding order itself as data: measuring the same waiting-list workload in contiguous-array, linked-node, and ring-buffer implementations by steps and bytes per entry, how many bytes per entry constant-step access from both ends is bought for, rank lookup being a scan in all three structures, and how trimming a recent-activity list lowers bytes held while narrowing the covered time window and the satisfied query rate.
  4. 04 Hash Structures The cost and the payoff of introducing object fields to the store: building the same book record in holistic-value, dense-hash, and per-field-entry shapes and measuring it under daily loan load by bytes held, bytes written, bytes read, round trips, and steps, per-field overhead roughly doubling record cost, and how the dense representation's memory gain is paid for in scan steps as field count grows, plus a threshold policy's catalog-wide outcome.
  5. 05 Sets and Sorted Sets The memory price of membership and rank questions: building the same on-loan book set as a list, sorted array, and hash-based set and measuring it in query steps, insertion steps, and bytes per entry, building the popular-book ranking on a member-score hash with three separate rank indexes, how much the skip list's pointer cost buys down the rank query, and how the sorted array buys nothing under update load.
  6. 06 Bitmaps and Probabilistic Structures The cost of keeping a member list when the number alone would do: the same distinct-reader question solved with an exact set, a bitmap, a probabilistic membership structure, and a cardinality estimate, the bytes each of the four structures holds read from its own buffer, the false positive rate measured, and how many bytes giving up certainty buys counted out.
  7. 07 Streams Treating the ordered event log as a data structure: the entry id built from time and sequence, the bytes per entry counted field by field, length and duration limits compared on a day's activity stream, and the unread share shown to determine the bytes held.
  8. 08 Spatial Indexes Building a proximity query with an in-memory structure: the same query solved with a flat scan, a cell bucket, and a spatial-keyed sorted set, the extra bytes each of the three structures holds and the candidates scanned per query measured, and what being able to choose the grain at query time costs counted out.
  9. 09 Server-Side Scripting Comparing multi-step work done atomically on the client versus in the store: the number of round trips, the race window, and the extra loans given out measured against concurrency, the memory of lock entries compared against the script cache, and how an unbounded script keeps every client waiting counted out.

02

Persistence and Memory Management

Durability and the memory limit turned into settings: snapshot persistence through periodic disk writes, the command log and its rewrite cost, the persistence choice between durability and performance, the eviction policies that decide which key gets evicted once the memory limit is reached, and expiration management's balance between lazy and active cleanup.

  1. 01 Snapshot Persistence The persistence form that writes the entire store to disk at intervals: how the interval affects the write count inside the data loss window, the disk cost of three intervals, the difference between the bytes held in memory and the size of the snapshot file, and the choice between pausing and copying while taking a snapshot.
  2. 02 Append Log Persistence The persistence form that records the write, not the state: how many bytes the command log holds per write, how the log grows relative to the snapshot, how much space the rewrite recovers, and the effect on the data loss window and write cost of syncing on every command, once per second, or leaving it to the operating system.
  3. 03 Persistence Selection Comparing four persistence schemes in the same crash scenario: how many steps recovery takes and which scheme builds an incomplete state, the data loss window, steady-state cost as bytes written to disk and sync count, and how the snapshot's job shifts from durability to recovery time once the two paths are used together.
  4. 04 Memory Limit and Eviction Policies Comparing the four policies that decide which key gets evicted once the memory limit is reached, on the same loan access trace: the share of the budget taken by the overhead a policy adds to entries, the number of entries that fit in the same budget, the hit rates measured across three budgets, and why time-based eviction fails to protect memory.
  5. 05 Expiration Management When expired keys actually drop out of memory: the dead bytes and delay left behind by the lazy method that cleans only on access, the per-round cost of the active method that samples the key space in the background, and the diminishing returns between dead memory and sampling work across three sample sizes.

03

Cluster and Usage Patterns

Moving beyond a single node and the store's everyday work: replication for read scaling and redundancy, automatic failover through sentinel processes, clustering by partitioning the key space, optimistic locking through watch-based collision control, publish-subscribe for lightweight messaging, catalog cache, session, rate limit, and leaderboard scenarios, performance diagnosis through slow command analysis, and authentication, network isolation, and encryption.

  1. 01 Replication The in-memory store moving beyond a single node: replication is not a setting but the forced consequence of how the store acknowledges writes, replica count and propagation delay run against the same workload to measure work per node, data held, stale reads, and their rate, the staleness window reduces to delay times write rate, the primary node's output buffer counts as memory, and a replica that cannot keep up overflows its buffer into full resync and offline rounds.
  2. 02 Automatic Failover The in-memory store's availability: testing the sentinel processes' majority decision when their own views diverge, measuring outage duration and false-failover count across eight sentinel settings, counting how shortening the detection threshold shortens the outage while growing false failovers and split writes, showing that asynchronous replication guarantees a per-failover loss of delay times write rate, and calculating what the full copy a hot backup holds buys against outage and loss.
  3. 03 Clustering Partitioning the key space: mapping a key to a slot by hash and a slot to a node, shown with a hand-written hash function, measuring the multi-key transaction's cross-node constraint across four node counts and comparing the single-node landing rate against the formula one over n to the power of k minus one, tagging keys into the same partition raising transactions to one hundred percent while narrowing the usable slot count to six, and counting how the tag's granularity trades multiplied bytes held against imbalance in load per node.
  4. 04 Transactions and Optimistic Locking Measuring watch-based collision control in an in-memory store: collisions and retries per job growing exponentially as concurrency doubles, comparing the same job across three schemes where the unconditional atomic step exceeds the limit eighty-six times without a single collision, watch overhead growing with client count until it exceeds the counter memory it protects, and counting how long a single-threaded store keeps every client waiting while a transaction block runs, as a function of block length.
  5. 05 Publish-Subscribe The in-memory store's lightweight messaging path and its lack of a delivery guarantee: counting the loss of a message published with no subscriber present, the bytes a slow subscriber's output buffer holds and the threshold at which it gets dropped, and the memory the same event stream pays when built with a persistent structure instead.
  6. 06 Typical Use Cases Fitting the catalog cache, session records, a rate limit, and a leaderboard onto the in-memory store's structures: which structure each scenario is built with, how many bytes it holds per entry, and what access that byte count buys.
  7. 07 Metrics and Slow Command Analysis Performance diagnosis for a single-threaded in-memory store: counting the number of requests waiting behind one long-running command and the total delay, what splitting a scan by cursor gains and what it misses, and sweeping the slow command log's threshold.
  8. 08 Security The store's configuration is a security decision: measuring the keys, bytes, and secret bytes opened to a stranger in a default setup with authentication off, showing that command restriction fully reopens the destructive surface it closed when server-side scripting is left on, network isolation moving the stranger outside the surface, and counting encryption's cost as an extra step per connection, extra bytes per frame, and a buffer per connection, working out that the buffer overtakes the data itself after ninety concurrent connections.

Start typing to search.

↑↓ ↵ Esc navigate · open · close