An in-memory task store keeps task records in a Go map while presenting a Store interface to the rest of the system. The wrapper moves map operations behind Put, Get, List, and Count, so managers and workers depend on storage behavior rather than on a particular map representation. section 11.3 section 11.5
Listing 11.3 The InMemoryTaskStore struct
type InMemoryTaskStore struct {
Db map[string]*task.Task
}
func NewInMemoryTaskStore() *InMemoryTaskStore {
return &InMemoryTaskStore{
Db: make(map[string]*task.Task),
}
}
The store owns a map from string keys to pointers to task records. Its constructor initializes that map, producing an empty store ready to receive tasks. section 11.3
Put accepts a string key and an interface value, asserts that the value is a *task.Task, then writes it to the map. Get looks up a key and returns an error when no task exists. List builds a slice of all stored task pointers, and Count returns the map length. section 11.3
Listing 11.4 The Put method
func (i *InMemoryTaskStore) Put(key string, value interface{}) error {
t, ok := value.(*task.Task)
if !ok {
return fmt.Errorf("value %v is not a task.Task type", value)
}
i.Db[key] = t
return nil
}
Put validates the boundary between the generic Store interface and task-specific storage before assigning the task pointer under its key. section 11.3
A manager selects this implementation when its database type is "memory" and assigns it through Store-typed task and event fields. Manager methods replace direct map reads and writes with Get, List, and Put; callers handle lookup errors and assert returned interface values back to *task.Task. section 11.5
Worker task lifecycle
A worker constructs the store through the same "memory" choice, saves a queued task with Put, retrieves it with Get, and writes updated task state after starting, failing, or completing work. Listing tasks similarly delegates to List instead of ranging over a worker-owned map. section 11.6
The task store is intentionally separate from the event store. A generalized store for both record types is possible, but adds concepts beyond this focused implementation. section 11.3
