store.Store separates task and event persistence from the manager and worker that use it. Instead of reaching into Go maps directly, those components depend on a small interface; an in-memory or persistent implementation handles storage details. This makes the datastore replaceable without changing orchestration logic. section 11.2 section 11.12
The interface sits between the manager and worker above it and interchangeable in-memory or persistent stores below it. section 11.2
The interface defines four operations: Put stores a value under a string key; Get retrieves one; List returns stored values; and Count reports their number. It omits deletion because the datastore is treated as a task-history record, though removal could support long-term maintenance. section 11.2
A map-backed task store
An InMemoryTaskStore wraps map[string]*task.Task. Its Put method checks that the supplied interface{} is a *task.Task before saving it; Get returns an error for a missing key; List builds a task slice; Count uses len. The wrapper keeps map mechanics inside the implementation. section 11.3
Manager task and event fields, and the worker task field, are typed as store.Store. Construction selects an implementation from a datastore-type string, then application code uses Get, Put, and List. Because results are returned as interface{}, callers type-assert them back to *task.Task or []*task.Task and handle errors. section 11.5 section 11.6
This boundary changes operational behavior in clear ways:
- A manager can persist queued events and tasks through Put rather than assigning into task and event maps. section 11.5
- A worker can store task state while running, failing, stopping, and updating tasks through the same interface. section 11.6
- Memory-backed stores preserve the refactoring but still lose tasks on restart; a persistent implementation is needed for restart recovery. section 11.7 section 11.12
- A persistent implementation built over BoltDB writes data to disk, allowing manager and worker restarts without losing tasks. section 11.12
The key tradeoff is deliberate: the interface makes callers independent of a concrete datastore, while task-specific implementations retain responsibility for validating and converting generic interface{} values. Separate task and event store types avoid introducing a more general store abstraction before it is needed. section 11.3 section 11.5
