Skip to main content

Multi-instance runtime (future)

Status: target, not shipped

The autoscaling mechanism is live in production (range 1–3, CPU + memory signals), deploys auto-rollback on the cluster-coordination correctness alarms, and the operational procedures ship at Operations → Multi-instance runtime runbook — see Current state → Multi-instance runtime. What remains is hardening: consolidated dashboards and production-shaped threshold validation.

CloudWatch dashboard rollout​

Today: Cluster-coordination signals are emitted as structured-log keys and consumed by individual alarms (one alarm per key). There is no consolidated multi-instance dashboard.

Target: A CloudWatch dashboard surfacing the cluster-coordination signals as a single operational view — adapter connect/disconnect cycle, broadcast resubscription gaps, lock unavailability rate, resource-lease reclaim rate, cron-fanout enqueue failures.

Open: Layout, time-window defaults, alarm-state integration.

Production load validation​

Today: The autoscaling thresholds (CPU 60%, memory 80%) are inherited from the develop/staging defaults. Production traffic shape may differ from the synthetic load that's been measured against those thresholds.

Target: Validated thresholds based on production traffic — either confirmed identical to defaults, or tuned per a documented load-test pass.

Open: k6 burn-in or equivalent against the production autoscaling boundary; threshold adjustment if needed.

Decisions still tracking​

The multi-instance work surfaced several deferred decisions covered in detail under ../decisions/deferred/:

Each is deliberately deferred with a documented revisit trigger — not a backlog item.