5e24215ffe
Co-authored-by: Copilot <copilot@github.com>
24 lines
1.4 KiB
Markdown
24 lines
1.4 KiB
Markdown
# 4. Solution Strategy
|
||
|
||
A short summary and explanation of the fundamental decisions and solution strategies that shape system architecture. It includes:
|
||
|
||
- Technology decisions
|
||
- Decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
|
||
- Decisions on how to achieve key quality goals
|
||
- Relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties
|
||
|
||
Micro‑service style: a single FastAPI process handles all API endpoints; a separate Flask process serves the UI.
|
||
|
||
| Quality Goal | Scenario | Solution Approach |
|
||
| ----------------- | ------------------------ | --------------------------------------------------------- |
|
||
| High availability | Service must be up 99.9% | Docker containers with health checks and restart policies |
|
||
| Low latency | Responses < 200 ms | FastAPI async endpoints; DuckDB in-process |
|
||
| Data privacy | Encrypted data | JWT auth, HTTPS everywhere, DuckDB file encryption |
|
||
|
||
**Key technology decisions:**
|
||
|
||
- **FastAPI** for async performance and automatic OpenAPI docs
|
||
- **DuckDB** for a lightweight embedded DB with no separate server
|
||
- **Flask** for a thin frontend layer with Jinja2 templates
|
||
- **openrouter.ai** for unified access to multiple AI model providers
|