Fault-domain clarity
Separate region, network and compute failure domains so recovery behaviour is deliberate rather than accidental.
2+fault domains per design
Active-activesupported topology
Privateservice paths
Runbooksoperational change model
VISUAL / SERVICE MODEL
See the architecture before reading the detail.
This view summarizes the service boundary, decision points and operational signals for Reference Architecture / Enterprise.
System topologyLOGICAL VIEW / NOT TO SCALE
The diagram represents the logical request or control path. Exact placement, capacity and failure-domain selection are defined during architecture review.
Operational signalsCONTROL PLANE
INGRESS
STEER
82%DOMAIN A
ACTIVE
67%DOMAIN B
ACTIVE
91%DATA
REPLICATE
74%Visual status indicators are conceptual UI examples and do not expose customer data.
01 / INGRESSSTEER
Traffic or control enters a defined service boundary.
02 / DOMAIN AACTIVE
Policy and placement are evaluated against current state.
03 / DOMAIN BACTIVE
The workload is processed by the appropriate infrastructure layer.
04 / DATAREPLICATE
Telemetry is preserved so the path can be explained operationally.
01 / DESIGN PREMISE
Start with failure domains and traffic shape.
Reference architecture at BitActive begins with the workload rather than a catalogue SKU. We model where state lives, where users enter the platform, how traffic changes during a fault, which components can be rebuilt, and which components must preserve continuity. That creates a topology that is explainable to both the application team and the infrastructure team.
After twelve years of infrastructure operations, one pattern remains consistent: systems become difficult to operate when the public edge, network, compute layer and recovery plan are designed independently. These solution patterns therefore compose dedicated and virtual compute, private networks, load balancing, edge delivery, storage and observability as one path.
02 / REFERENCE PATH
A topology that can be reasoned about.
The actual deployment is tailored during architecture review, but the control boundaries remain explicit.
BITACTIVE / REQUEST PATHARCHITECTURE
Anycast edgeSTAGE 01
Security policySTAGE 02
Load balancerSTAGE 03
Primary regionSTAGE 04
Standby regionSTAGE 05
The diagram is a logical service path. Exact routing, placement and capacity are selected per workload and service profile.
03 / ARCHITECTURE PRINCIPLES
Build for the operational reality.
Controlled ingress
Keep public traffic at the edge and expose only the service paths that are designed to be reachable.
Reserved capacity
Plan compute and network headroom for failover instead of discovering capacity constraints during an incident.
Operational evidence
Use telemetry, event history and versioned configuration to support reviews and controlled change.
04 / DELIVERY MODEL
Premium engagements are architecture-led.
BitActive services are provided as premium infrastructure engagements rather than anonymous public sign-ups. A prospective project is reviewed for topology, traffic profile, capacity, security and operational fit. This keeps the platform focused on workloads where a managed engineering relationship adds value.
There is no public customer directory and no client names are used as marketing proof. Technical authority is demonstrated through architecture detail, operating practices and the technology stack itself. Commercial terms, service schedules and formal agreements are provided directly to the prospective client before any commitment is made.
Discuss the architecture.
BitActive works with referred clients on premium infrastructure engagements. Start with the workload, traffic profile and operational requirements.