generated from john/python-template
33 lines
1.0 KiB
Markdown
33 lines
1.0 KiB
Markdown
# ADR-0004: In-process worker topology for V1
|
|
|
|
- **Status:** accepted
|
|
- **Date:** 2026-06-25
|
|
|
|
## Context
|
|
|
|
The current system uses an in-process background worker. Architecture docs allow this in foundation stage and permit later hardening (optional external worker/queue).
|
|
|
|
## Decision
|
|
|
|
Retain in-process worker topology for V1, with improved lifecycle ownership:
|
|
|
|
1. Worker starts/stops via app lifespan.
|
|
2. Worker receives runtime-owned DB engine dependency explicitly.
|
|
3. Extension path to external worker remains behind existing service/adapter seams.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
- Keeps operational complexity low for personal-scale use.
|
|
- Preserves delivery focus on V1 completion.
|
|
|
|
### Tradeoffs
|
|
- Throughput/scaling limits remain compared to external queue-based topology.
|
|
|
|
## Alternatives Considered
|
|
|
|
1. **Immediate queue/external worker introduction**
|
|
- Rejected: premature complexity for current scale.
|
|
2. **Ad hoc thread lifecycle management outside lifespan**
|
|
- Rejected: weaker shutdown guarantees and poorer ownership clarity.
|