Known Constraints and Tradeoffs¶
Purpose¶
Set explicit expectations for architectural constraints and tradeoffs before major changes.
Key Constraints¶
- async workflows may introduce eventual consistency
- deploy service naming may differ from local naming
- cross-module coupling must remain explicit
Tradeoff Table¶
| Decision | Benefit | Tradeoff |
|---|---|---|
| monolith + domain modules | easier cross-domain traceability | strict boundary discipline required |
| Redis + Celery async | non-blocking request path | queue operations and monitoring overhead |
| dual compose runtime | local/deploy consistency | additional runtime-doc maintenance |
Practical Impact¶
- design UX/workflows for delayed async completion where needed
- validate changes in both runtime modes for high-impact features
- prefer explicit integration contracts over convenience imports
How to use this page
Review this before large refactors, architecture-level decisions, or infrastructure changes.