A database process isolates persistence behind a concurrent server. Clients store values by key and retrieve them later, while the process serializes file access and hides its PID through local registration. section 7.3.1
The simple implementation stores each key in a same-named file, encoding arbitrary Erlang terms as binaries. It favors clarity over production robustness so concurrency behavior remains visible. section 7.3.1
The request interface makes an explicit availability–consistency trade-off:
- Use a cast for store when callers need no response; they continue immediately, improving responsiveness and scalability. section 7.3.1
- Use a call for get when callers require the retrieved value. section 7.3.1
- Accept that casts provide no confirmation that a request arrived or succeeded, weakening consistency guarantees. section 7.3.1
The surrounding system starts the database from the cache, persists a to-do list after each modification, and loads it on first initialization. Long disk reads should not block GenServer.start, so two-phase initialization defers loading to handle_continue/2. section 7.3.2
Persisting a named list
Todo.Server.add_entry updates its in-memory list and calls Todo.Database.store(name, new_list). On restart, the server retrieves that name and restores the saved list, or creates an empty list when no file exists.
