generated from john/python-template
Implemented v1 step1
This commit is contained in:
@@ -0,0 +1,32 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user