| R1 | Single SQL Server instance — All services share one SQL Server container. A failure takes down all services simultaneously. | Medium (development) / High (if used as production blueprint) | High | Acceptable for development/demo. A production deployment would use separate SQL Server instances or a managed database service. See ADR-0007. |
| R2 | No authentication or authorization — The system has no security measures. APIs are open, and credentials are in configuration files. | N/A (by design) | High (if deployed publicly) | Intentional omission for a demo application. Must be addressed before any production use. |
| R3 | TimeService as single point of failure — If the TimeService is down, no DayHasPassed events are published, and daily processing (notifications, invoices) does not occur. | Low | Medium | The TimeService is a very simple service with few failure modes. In production, a persistent scheduler or managed cron service would be more appropriate. |
| R4 | RabbitMQ as single point of failure — A RabbitMQ outage blocks all asynchronous communication. | Medium | High | Acceptable for a demo. Production would use RabbitMQ clustering or a managed message service. |
| R5 | Eventual consistency confusion — Conference audience or developers unfamiliar with eventual consistency may see stale data and assume it is a bug. | Medium | Low | Covered by documentation and live explanation during talks. Seq logging helps trace event propagation. |