Multi-Region Deployment (Planned)

Not available today. KnoxCall runs in a single region (DigitalOcean, New York) and serves every tenant from it. There is no multi-region deployment, no cross-region failover, no regional data residency and no availability commitment attached to any of this yet. Everything below describes planned functionality and may change before it ships. If you are interested in multi-region support, contact our sales team to be notified when it becomes available.

When it ships, multi-region deployment is intended to run KnoxCall in several geographic regions, for lower-latency API access worldwide, data residency, and higher availability.

Why Multi-Region?

Performance

Reduce latency by routing requests to the nearest region:

User in Tokyo → Asia-Pacific Region (50ms)
vs.
User in Tokyo → US East Region (200ms)

Illustrative figures, not measurements.

Compliance

Meet data residency and sovereignty requirements:

GDPR: EU data must stay in EU
CCPA: California data preferences
HIPAA: Healthcare data location requirements

High Availability

The plan: if one region goes down, traffic would route to another. Today there is one region, so there is nothing to fail over to.

US East: ❌ Down
    ↓
Automatic failover
    ↓
US West: ✅ Serving traffic

Planned Regions

The planned region model defines four regions:

🇦🇺 New Zealand / Australia

Sydney, Australia (nz)

NZ + Australia data residency
Serves NZ, AU

🇺🇸 United States

Oregon, United States (us)

Americas + Asia coverage
Primary region

🇩🇪 Europe

Frankfurt, Germany (eu)

GDPR-aligned EU data residency
Serves UK + EU

🌐 Global

global

For tenants that opt out of regional pinning
Served from any region

How It Works

Automatic Routing

Requests are planned to be routed to the nearest region:

Client Location: London, UK
    ↓
DNS Resolution
    ↓
Nearest Region: EU West (Ireland)
    ↓
Request routed to EU West
    ↓
Low latency: ~20ms

Data Synchronization

Your configuration is planned to be synchronized across all regions:

Routes: Instantly synchronized
Secrets: Replicated encrypted
Clients: Available in all regions
Logs: Aggregated centrally

Region Selection

Three region-selection modes are planned:

1. Automatic (Recommended)

KnoxCall would route to the nearest region:

User → Closest Region

Best for: Most use cases

2. Pinned Region

Pin a tenant to a specific region so its data is only served from that region. Region pinning is planned to be driven by the tenant’s residency configuration (the SERVER_REGION of each regional deployment plus the tenant’s assigned region), not a per-request header. Best for: Data residency requirements

3. Per-Route Region

Configure default region per route:

Route: customer-data-api
Default Region: eu (GDPR compliance)

Route: global-api
Default Region: auto (nearest)

Setting Up Multi-Region (Planned)

Step 1: Enable Multi-Region (Enterprise)

Multi-region cannot be enabled on any plan today. The steps below describe the planned setup:

Contact sales or support
Enable multi-region for your tenant
Select regions to deploy to

Step 2: Configure Routes

For each route, choose regional strategy:

Navigate to Routes → Select route
Go to Regional Configuration tab
Select mode:

Automatic Routing:

Region Selection: Automatic
Fallback Region: us

Pinned Region:

Region Selection: Pinned
Primary Region: eu

Multi-Region Active-Active:

Region Selection: Active-Active
Regions: us, eu, au
Load Balancing: Geo-proximity

Save configuration

Step 3: Test Regional Routing

Test from different locations by confirming requests resolve to the expected regional endpoint:

curl https://a1b2c3d4.acme.knoxcall.com/api/test \
  -H "x-knoxcall-route: my-route" \
  -v

A request from a US-based client is planned to resolve to the us (Oregon) deployment, while a request from an EU-based client resolves to the eu (Frankfurt) deployment, based on the tenant’s residency configuration.

Data Residency Configuration (Planned)

Planned route-level residency settings. None of them can be set today:

Route: eu-customer-data
Regions: eu
Data Residency: Enforce EU only
Failover: Within EU only

US Data Residency

Route: us-customer-data
Regions: us
Data Residency: Enforce US only
Failover: Within US only

Multi-Regional with Restrictions

Route: global-api
Regions: All regions
EU Traffic: Must use the eu region
US Traffic: Must use the us region
NZ/AU Traffic: Must use the nz region

Failover & High Availability (Planned)

Automatic Failover (planned)

If a region becomes unhealthy, the planned behaviour is:

Primary: US East → ❌ Health check fails
    ↓
Traffic switches to: US West ✅
    ↓
User requests continue uninterrupted
    ↓
When US East recovers → Traffic returns

Health Checks

The planned health checks:

Frequency: Every 10 seconds
Threshold: 3 consecutive failures triggers failover
Checks:
- API endpoint responsiveness
- Database connectivity
- Latency < 1000ms
- Success rate > 95%

Regional Status Page

Once multi-region ships, per-region health will be published on the status page. The layout below is illustrative — KnoxCall serves from one region today, and no per-region availability figure is published until there is one to measure: 🟢 US East: Operational 🟢 US West: Operational 🟢 EU West: Operational 🟢 EU Central: Operational 🟢 APAC: Operational Visit: https://status.knoxcall.com

Performance Benefits (Planned)

Latency Reduction

Modelled round-trip times for the planned topology — these are illustrative, not measurements. KnoxCall serves from a single region today:

User Location	Single Region (US East)	Multi-Region	Improvement
New York	20ms	20ms	-
Los Angeles	80ms	25ms	69% faster
London	120ms	15ms	88% faster
Singapore	250ms	30ms	88% faster
Sydney	200ms	50ms	75% faster

Global Coverage Map

      🇺🇸 US West     🇺🇸 US East
         25ms            20ms
              ╲        ╱
                ╲    ╱
                 User
                ╱    ╲
              ╱        ╲
         15ms            30ms
      🇪🇺 EU West    🇸🇬 APAC

Monitoring Multi-Region (Planned)

Regional Metrics Dashboard

Monitor performance per region:

Request volume per region
Average latency per region
Error rate per region
Failover events

Alerts

Set up regional alerts:

Alert: Region Degraded
Condition: Latency > 500ms for 5 minutes
Notification: Email, Slack, PagerDuty

Alert: Regional Failover
Condition: Traffic switched to backup region
Notification: Immediate SMS, Email

Cost Considerations (Planned)

Data Transfer

Pricing for multi-region, including any cross-region data transfer, has not been set. Optimization:

Pin routes to single region when possible
Use multi-region only for global applications

Best Practices (Planned)

1. Use Automatic Routing by Default

Unless you have specific compliance needs:

Region Selection: Automatic

2. Pin Compliance-Sensitive Routes

For GDPR, HIPAA, or other compliance:

Route: patient-data
Regions: us (HIPAA)
Data Residency: Enforce US only

3. Test Failover

Regularly test failover:

Simulate region failure
Verify traffic switches to backup
Ensure data consistency

4. Monitor Regional Performance

Set up dashboards per region:

Latency trends
Error rates
Traffic distribution

5. Configure Appropriate Failover

Critical routes:

Failover: Automatic, within 30 seconds
Backup regions: 2

Non-critical routes:

Failover: Manual approval required

Troubleshooting (Planned)

High latency despite multi-region

Check:

DNS propagation (24-48 hours)
Regional assignment correct
Client using correct endpoint

Requests going to wrong region

Causes:

DNS caching
VPN routing
Pinned region configuration

Fix:

Clear DNS cache
Verify the tenant’s assigned residency region
Verify route configuration

Failover not working

Check:

Health checks enabled
Backup region configured
Failover policy active

Next Steps

Rate Limiting

Protect your APIs

Alerts

Monitor regional health

Security

Secure your routes

Analytics

Monitor regional performance

📊 Statistics

Level: advanced
Time: 15 minutes

🏷️ Tags

multi-region, global, performance, compliance, high-availability

​Multi-Region Deployment (Planned)

​Why Multi-Region?

​Performance

​Compliance

​High Availability

​Planned Regions

🇦🇺 New Zealand / Australia

🇺🇸 United States

🇩🇪 Europe

🌐 Global

​How It Works

​Automatic Routing

​Data Synchronization

​Region Selection

​1. Automatic (Recommended)

​2. Pinned Region

​3. Per-Route Region

​Setting Up Multi-Region (Planned)

​Step 1: Enable Multi-Region (Enterprise)

​Step 2: Configure Routes

​Step 3: Test Regional Routing

​Data Residency Configuration (Planned)

​GDPR Compliance (EU)

​US Data Residency

​Multi-Regional with Restrictions

​Failover & High Availability (Planned)

​Automatic Failover (planned)

​Health Checks

​Regional Status Page

​Performance Benefits (Planned)

​Latency Reduction

​Global Coverage Map

​Monitoring Multi-Region (Planned)

​Regional Metrics Dashboard

​Alerts

​Cost Considerations (Planned)

​Data Transfer

​Best Practices (Planned)

​1. Use Automatic Routing by Default

​2. Pin Compliance-Sensitive Routes

​3. Test Failover

​4. Monitor Regional Performance

​5. Configure Appropriate Failover

​Troubleshooting (Planned)

​High latency despite multi-region

​Requests going to wrong region

​Failover not working

​Next Steps

Rate Limiting

Alerts

Security

Analytics

📊 Statistics

🏷️ Tags

Multi-Region Deployment (Planned)

Why Multi-Region?

Performance

Compliance

High Availability

Planned Regions

How It Works

Automatic Routing

Data Synchronization

Region Selection

1. Automatic (Recommended)

2. Pinned Region

3. Per-Route Region

Setting Up Multi-Region (Planned)

Step 1: Enable Multi-Region (Enterprise)

Step 2: Configure Routes

Step 3: Test Regional Routing

Data Residency Configuration (Planned)

GDPR Compliance (EU)

US Data Residency

Multi-Regional with Restrictions

Failover & High Availability (Planned)

Automatic Failover (planned)

Health Checks

Regional Status Page

Performance Benefits (Planned)

Latency Reduction

Global Coverage Map

Monitoring Multi-Region (Planned)

Regional Metrics Dashboard

Alerts

Cost Considerations (Planned)

Data Transfer

Best Practices (Planned)

1. Use Automatic Routing by Default

2. Pin Compliance-Sensitive Routes

3. Test Failover

4. Monitor Regional Performance

5. Configure Appropriate Failover

Troubleshooting (Planned)

High latency despite multi-region

Requests going to wrong region

Failover not working

Next Steps