A key-value store associates each value with a key and supports direct operations such as retrieving or updating a value by that key. A hash map provides a simple in-memory implementation; a durable database can replace it when persistence matters. section 4.8
The interface is effective when data access is simple enough to avoid transactions or complex queries. Caching commonly uses keys such as user IDs with profiles, settings, or session data as values, but freshness and consistency become important trade-offs. section 6.1
A replicated design adds an operational structure around the store:
- A primary accepts writes and broadcasts Put updates to replicas. section 4.8
- A joining replica receives a Snapshot before applying incremental updates. section 4.8
- Replicas can serve local reads, reducing access latency while introducing replication and consistency concerns. section 4.8 section 6.1
Primary and replica shells
Start a primary with PUT and GET commands, store a = 1 and b = 2, then start a replica. Before joining, the replica returns Not found; after JOIN localhost:8080, it receives a snapshot and returns a = 1 and b = 2. A later primary write, c = 3, becomes readable on the replica. section 4.8
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);
}
}
Inspect the compact Rust implementation of the store’s mutex-protected HashMap, including get and put operations. section 4.8
