Platform InfrastructureAfriRoute-advanced
A reference architecture for carrier-grade delivery, reliability, and governance
These pages document the platform layers that power multi-carrier messaging, voice, USSD, and contact center operationsincluding telecom gateway flows and audit-ready log taxonomy.
Infrastructure layers (diagram)
A simplified map of the edge, API plane, governance and shared routing core, and telecom partner planes.
Telecom gateway operator flow
How we translate API intents into operator traffic, receipts, retries, compliance checks, and settlement events.
Call center logs taxonomy
A unified event/log model across human + AI agents, queues, CRM integrations, QA, and audit boundaries.
Governance-by-design
Infrastructure-specific controls: RBAC, data boundaries, approvals, kill-switches, and audit trails.
What this covers
- Global edge + regional ingress patterns for Africa/EU/US
- Unified API surface: auth, idempotency, quotas, events/webhooks
- Governed automation: approvals, policy engine, kill-switches
- Telecom gateway planes: operator flows, receipts, retries, settlement
Audience
- Enterprise architects and procurement
- Operators/aggregators and ecosystem partners
- Platform and data engineering teams
- Security/compliance stakeholders
How to use this
- Start with the map, then dive into the telecom gateway flow
- Adopt the logging taxonomy for unified operations + audits
- Use the security pages for control mapping
- Reach out for reference deployments
Infrastructure Transparency
We publish our architecture, isolation model, and operational targets — not vague “enterprise-grade” marketing.
Transparency commitment
Three-Layer Architecture
Layer 1
AI & Governance Layer
- •AI routing optimisation
- •Fraud & abuse detection
- •Policy engine + RBAC
- •Confidence scoring & escalation
- •Kill switch controls
- •Audit evidence export
Layer 2
CPaaS API Layer
- •Unified REST API surface
- •Webhook event delivery
- •Rate limiting & quotas
- •Sandbox ↔ production isolation
- •SDK + CLI tooling
- •Idempotency controls
Layer 3
Carrier Infrastructure Layer
- •SS7 & SMPP interconnects
- •SIP trunking
- •USSD gateway integration
- •Mobile money rails
- •Delivery receipt normalisation
- •Multi-carrier failover
Data Residency
South Africa
POPIA
AvailableWest Africa (Nigeria)
NDPR
AvailableEast Africa (Kenya)
DPA 2019
AvailableEurope
GDPR
PlannedData residency constraints are enforced at the policy evaluation layer. No payload crosses region boundaries without explicit policy approval.
Multi-Tenant Isolation Model
Logical isolation
- •Tenant ID required on every API call
- •Rejected if missing or mismatched
- •Project-per-tenant workspace pattern
- •Separate API keys and webhook endpoints
Data isolation
- •Tenant-scoped database queries
- •No cross-tenant data leakage by design
- •Dedicated encryption keys per tenant (enterprise)
- •Audit logs scoped to tenant boundary
Compute isolation
- •Rate limiting per tenant and per intent
- •Noisy-neighbour protection
- •Priority queues for high-SLA tenants
- •Sandbox and production environment separation
Network isolation
- •VPC peering for enterprise deployments
- •IP allowlisting available
- •mTLS for inter-service communication
- •Webhook signature verification per tenant
Rate Limiting & Quotas
| Scope | Default Limit | Configurable | Response |
|---|---|---|---|
| API requests (per tenant) | 1,000 req/min | Yes | 429 + Retry-After header |
| SMS sends (per tenant) | 100 msg/sec | Yes (enterprise) | Queued with backpressure |
| Webhook deliveries | 500 events/sec | No | Exponential retry |
| AI inference | 50 req/min | Yes | Fallback to rule-based |
Disaster Recovery & Business Continuity
RTO (Recovery Time Objective)
< 4 hours
Target for full service restoration
RPO (Recovery Point Objective)
< 1 hour
Maximum acceptable data loss window
Backup frequency
Continuous + daily snapshots
Write-ahead logs + point-in-time recovery
Failover
Automated multi-region
Health checks trigger automatic carrier failover
Transparency note: These are design targets. Actual RTO/RPO depend on incident type and will be published in post-incident reports once the platform is in general availability.
Circuit Breaker Pattern
Closed
Normal operation. All requests flow through. Error counters monitored per carrier and route.
Open
Carrier/route isolated. All traffic rerouted to fallback chain. Incident event emitted to observability stack.
Half-Open
Probe requests sent to test recovery. If successful, circuit closes. If failed, stays open with extended cooldown.
Circuit breaker thresholds are configurable per carrier, per route, and per tenant. Every state transition is logged with traceId, timestamp, and blast radius.
Next: deep dives
Explore the operator gateway flow and adopt a production-ready audit/log taxonomy for contact center operations.