Hybrid network architecture: Starlink plus terrestrial fiber
Design principles for combining satellite and terrestrial paths—roles, failover philosophy, and what ‘backup’ must never pretend to be.
Assign roles explicitly
| Role | Typical fit | Expectation |
|---|---|---|
| Primary | Fiber / reliable terrestrial | Stable throughput, predictable latency |
| Backup / overflow | Starlink or secondary WAN | Continuity first; performance second |
| Primary in remote sites | Starlink (when terrestrial is weak) | Accept variability; design apps accordingly |
Write the role down. If sales promises “fiber-like Starlink primary” for a latency-sensitive app, architecture cannot save the account later.
Failover philosophy
Three common patterns:
- Active–passive — backup idle until primary fails. Simple; watch for silent backup rot (untested paths).
- Active–active with policy — both carry traffic; steer classes (bulk vs. interactive). More complex; needs clear policy.
- Overflow — primary until congestion or brownout; satellite absorbs excess. Needs honest capacity models.
Whatever you choose, health checks must be independent. Checking only the CPE’s default route will miss “primary is up but useless.”
What breaks hybrids in the wild
- Backup never exercised until the outage
- Asymmetric routing and stateful firewalls
- DNS and app timeouts longer than your failover
- Monitoring that only pings the LAN side of the router
- Billing and capacity planning that assume backup is free unlimited primary
Design checklist
- Define RTO for the site (how long may it be dark?)
- Define which apps may degrade on backup (backup ≠ clone)
- Probe both underlays from beyond the router
- Test failover on a schedule, not only after incidents
- Document who gets paged when backup becomes primary for >N minutes