A map stores values by key so a caller can retrieve a value without scanning every entry. A hash map is one implementation. It can hold ordinary application state, or serve as a lookup table for results computed before a latency-sensitive request arrives. section 4.8 section 7.6
The performance gain is about growth, not a guaranteed lookup time. Hash-table search is O(1) on average, versus O(n) for a linear scan of an array. Collisions can make hash-table search O(n) in the worst case. Big O describes how work grows with input size, not how many milliseconds an operation takes. section 7.2
pub struct KVStore {
data: Mutex<HashMap<String, String>>,
}
impl struct KVStore {
pub fn get(&self, key: &str) -> Option<String> {
self.data.lock().unwrap().get(key).cloned()
}
pub fn put(&self, key: String, value: String) {
self.data.lock().unwrap().insert(key, value);
}
}
A Rust key–value store wraps a HashMap<String, String> in a Mutex. Its get method locks the map and returns a cloned value if the key exists; put locks it and inserts a pair. section 4.8
Local reads on a replica
A primary stores pairs such as (a, 1) and broadcasts later writes. A new replica first receives a snapshot, then applies updates, allowing its local map to answer GET requests. Before joining, its GET requests find nothing. The in-memory map provides the backing store, not durable storage. section 4.8
For a precomputed lookup table, do the expensive calculation at build time, startup, or another convenient time; store the result under a key; then look it up on the request path. Storage-usage statistics are one candidate when calculating them on demand could take seconds. The trade-off is freshness: periodically computed values can become stale, while incremental updates can keep a more current snapshot without repeating the full calculation. section 7.6
