# fetch_ml Configuration Guide

## Quick Start

### Standalone Mode (Existing Behavior)
```bash
# Single worker, direct queue access
go run ./cmd/worker -config configs/worker/standalone/worker.yaml
```

### Distributed Mode
```bash
# Terminal 1: Start scheduler
go run ./cmd/scheduler -config configs/scheduler/scheduler.yaml

# Terminal 2: Start worker
go run ./cmd/worker -config configs/worker/distributed/worker.yaml
```

### Single-Node Mode (Zero Config)
```bash
# Both scheduler and worker in one process
go run ./cmd/fetch_ml -config configs/multi-node/single-node.yaml
```

## Config Structure

```
configs/
├── scheduler/
│   └── scheduler.yaml       # Central scheduler configuration
├── worker/
│   ├── standalone/
│   │   └── worker.yaml      # Direct queue access (Redis/SQLite)
│   └── distributed/
│       └── worker.yaml      # WebSocket to scheduler
└── multi-node/
    └── single-node.yaml     # Combined scheduler+worker
```

## Key Configuration Modes

| Mode | Use Case | Backend |
|------|----------|---------|
| `standalone` | Single machine, existing behavior | Redis/SQLite/Filesystem |
| `distributed` | Multiple workers, central scheduler | WebSocket to scheduler |
| `both` | Quick testing, single process | In-process scheduler |

## Worker Mode Selection

Set `worker.mode` to switch between implementations:

```yaml
worker:
  mode: "standalone"    # Uses Redis/SQLite queue.Backend
  # OR
  mode: "distributed"   # Uses SchedulerBackend over WebSocket
```

The worker code is unchanged — only the backend implementation changes.