Day 7: Architecture Review

Phase 7 · Sep 29, 2026

Architecture Review Checklist

Before writing code, validate the design against each phase's key concepts.

Phase 1 — Fundamentals:

• [ ] Consistency model: is DynamoDB eventually consistent or strongly consistent for task claim? (SC required for atomic claim)
• [ ] Is the SQS + DynamoDB combination consistent enough for at-least-once processing?

Phase 2 — Async Rust:

• [ ] Tokio worker tasks bounded by JoinSet?
• [ ] CancellationToken wired to SIGTERM for graceful shutdown?
• [ ] SQS long-poll loop uses select! with cancellation?

Phase 3–4 Review

Phase 3 — Protocols:

• [ ] gRPC server-streaming for ListTasks uses tonic mpsc sender?
• [ ] mTLS configured between API service and clients?
• [ ] gRPC deadlines propagated to DynamoDB calls?

Phase 4 — Reliability:

• [ ] Circuit breaker on DynamoDB client for throttle events?
• [ ] SQS visibility timeout heartbeat loop for long-running tasks?
• [ ] Outbox pattern: SQS send happens in same DynamoDB transaction via TransactWriteItems?
• [ ] Idempotency key checked before any state mutation?

Phase 5–6 Review

Phase 5 — AWS Primitives:

• [ ] SQS FIFO with MessageGroupId = task_type for ordering?
• [ ] DynamoDB on-demand capacity mode selected?
• [ ] ECS task definition reviewed for security: no hardcoded secrets, task role scoped?

Phase 6 — Observability:

• [ ] trace_id in every log event via with_current_span(true)?
• [ ] All four golden signal metrics defined?
• [ ] Alert runbooks written before implementation?
• [ ] SLO error budget defined and alerted?

Green Light Criteria

All checklist items above must be ticked before starting Week 2 implementation.

For any unchecked item:

1. Identify which day's material resolves it
2. Re-read that day's content
3. Update the design
4. Re-check

Tomorrow: implementation begins — SQS worker loop.