Feature: Multi-Region
Region-aware.
Multi-region capability
Multi-region in Nova is designed around giving customers a clear region story without forcing the choice on every team. This describes the design and rollout shape; specific region availability is staged with early customers as the platform matures.
- Single-tenant multi-region. Customer data and incident processing pinned to chosen regions; metadata replicated globally so dashboards and identity work across regions.
- Two deployment models. Replicated active-active or pinned active-passive per customer; choice based on compliance preferences and cost trade-offs.
- Single-region latency for the hot path. Dashboards and incident response stay within a single region; cross-region only for explicit operations like global search or aggregation.
- Named region owner per tenant. Responsible team per tenant supports compliance reviews and audit conversations.
Architecture
The architecture splits responsibility across data plane and control plane. Region-affinity for data; global replication for control. The pattern keeps the read path local while preserving global identity and billing.
- Per-region data plane. Incident store, metric backend, and configuration cache per region; region-affinity for all customer-facing read and write paths.
- Global control plane. Global configuration, identity, and billing per tenant; replicated for read across regions, central writes flow through a primary.
- Cross-region replication is opt-in. Per-customer replication choice; regulated industries can disable replication and accept reduced disaster recovery scope.
- Per-region storage encryption. KMS key per region supports compliance posture and customer-managed key requirements.
Compliance considerations
Compliance is the reason multi-region exists. Data residency, audit trail, and encryption together support the GDPR, industry-specific, and customer-specific commitments that make region pinning real rather than aspirational.
- Data residency. Customer-data location guarantee per tenant; required for GDPR data subjects in the EU and for some industry regulations.
- Audit trail. Per-region audit log with cross-region aggregation for security teams that need a unified view.
- Encryption. Customer-managed KMS keys per region; BYOK option for highest-sensitivity workloads.
- Data-residency contract per tenant. Explicit residency commitment per tenant supports auditor reviews and customer security questionnaires.
Operating multi-region
Operating multi-region is its own discipline. Region-status indicators, failover models, and pricing each need to be designed deliberately so customers and on-call both have a clear picture of what works when.
- Per-region status indicators. Region-health dashboard per customer; customers see whether issues are region-specific or global.
- Failover models. Manual failover in pinned mode, automated failover in replicated mode; clarity per tenant on which model applies.
- Pricing structure. Multi-region positioned as part of higher-tier offerings; specific pricing firms up alongside the rollout.
- Failover drill per tenant. Periodic failover test catches latent failure modes before they become incidents.
Rollout shape
The rollout is staged by region with early customers participating in each region's GA validation. Specific region availability and timing firm up as the platform proves out per region; the documentation tracks current availability rather than a published schedule.
- Staged regional rollout. Each region GAs after early-customer validation; we list current availability rather than a forward calendar.
- Customer-requested regions. Additional regions surface from customer demand; the rollout follows the customer base rather than a generic plan.
- Pre-GA readiness checklist per region. Validation before GA supports launch quality; we do not list regions as available before the checklist passes.
- Documented availability. Current region availability published and updated in product documentation; customers see actual rather than aspirational state.