docs: rails-poc spec §7 — HA, split into Tito-side and CARLOS-side concerns
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 file changed,
+24
−0
docs/superpowers/specs/2026-08-11-rails-behind-carlos-edge-poc-design.md+24 −0
diff --git a/docs/superpowers/specs/2026-08-11-rails-behind-carlos-edge-poc-design.md b/docs/superpowers/specs/2026-08-11-rails-behind-carlos-edge-poc-design.md| index e4f594543..7408f692c 100644 |
| --- a/docs/superpowers/specs/2026-08-11-rails-behind-carlos-edge-poc-design.md |
| +++ b/docs/superpowers/specs/2026-08-11-rails-behind-carlos-edge-poc-design.md |
| @@ -205,6 +205,30 @@ the migration evaluation: |
| with no rebuild and no compatibility issue — the deferral cost |
| nothing for the PoC itself; the arm64 gap for a real deployment |
| stands as stated. |
| +7. **High availability** (added 2026-08-12, Paul's question). The PoC has |
| + deliberately little: one box per app, one AZ, edge proxying to one IP; |
| + `Restart=always` covers process death and nothing covers box death. |
| + The layers split cleanly into two owners, and **nothing Tito-side |
| + waits on anything CARLOS-side**: |
| + - **Tito concerns** (this migration's own work, plain AWS, no platform |
| + changes): EC2 auto-recovery on the boxes; N boxes per app behind an |
| + internal NLB with the edge's `-addr` pointed at the NLB (multi-AZ, |
| + health-checked failover, rolling zero-downtime deploys — and |
| + networking-trivial in prod, where the existing peering already routes |
| + the whole VPC); Classic's supercronic → sidekiq-ent so cron stops |
| + being a single-box constraint (Pro's already is, with Redis-backed |
| + single-fire); the hostname/host-authorization config. |
| + - **CARLOS concerns** (roadmap candidates, priced by whether |
| + Rails-on-CARLOS graduates from migration tactic to product): |
| + multi-upstream health-checked `addr` routes at the edge — the |
| + platform-native replacement for the NLB rung; and the edge's own HA |
| + posture (standby/EIP failover), which is a whole-deployment question |
| + every CARLOS tenant shares — the Rails apps widen the blast radius of |
| + a risk `go.tito.io` already carries, they don't create it. |
| + - Data HA is out of scope by construction: Postgres/MySQL/Valkey/ |
| + Memcached stay in RDS/Elasticache with their own multi-AZ story — |
| + the apps' state was never on k8s, so the migration never touches the |
| + layer where losing things actually hurts. |
| **2026-08-11:** staging is live on both apps (see `tito/README.md`'s Rails |
| PoC section in platform-infrastructure for current status). The edge |