An in-memory database stores task and event state in process memory. In a task orchestrator, it provides a concrete Store implementation behind the same interface used by the manager and worker, so callers can save and retrieve state without depending on map internals. section 11.2 section 11.5
The store sits between orchestration components and concrete storage choices: both the manager and worker use one Store interface, while in-memory and persistent stores supply the implementation. section 11.2
The interface defines four operations: Put stores a value under a string key, Get retrieves one value, List returns stored values, and Count reports their number. A deletion operation is omitted because task history is treated as a record, though removal could support datastore maintenance. section 11.2
Typed task-event store
A task-event store wraps a map from strings to pointers to task events. Its Put method checks that the supplied value is a task-event pointer before inserting it; Get returns an error for a missing key; List builds a slice by iterating over the map. A task store follows the same pattern for task values. section 11.4
Use an in-memory store through the abstraction rather than direct map access:
- Choose the memory datastore type during manager construction, then create separate task and event stores. section 11.5
- Retrieve a task with Get, handle a missing-key error, and type-assert the returned interface value before updating it. section 11.5
- Write changed task state back with Put, and obtain task collections with List rather than ranging over the backing map. section 11.5
This design decouples orchestration logic from the storage mechanism. The same manager and worker code can select memory for development or a persistent implementation for production by passing a datastore type to construction. The tradeoff is durability: map-backed state disappears when the manager or worker restarts, while a persistent store can retain tasks and events on disk for recovery. section 11.12 section 11.5
