LinkedIn Professional Network · View 22 of 30 · 6 · Operations
Decisions
- Four serving colos, all active (LinkedIn, 2017). The traffic tier pins each member to one colo with a signed cookie
- Losing a colo is routine: TrafficShift drains it by re-pinning members elsewhere, the same mechanism LinkedIn uses for load tests (LinkedIn, 2017)
- The global edge has been on Azure Front Door since 2020, replacing LinkedIn's own 19 PoPs
RPO and RTO
- Service failure: restart in seconds, no data loss
- Fault-zone loss: RPO 0 through in-colo replicas; RTO under 1 minute, automatic
- Colo loss: RPO of seconds through async cross-colo replication; RTO under 15 minutes by traffic shift. Derived stores are rebuilt, so RPO does not apply to them
Risks
- A write acknowledged in a colo that then dies can be lost for seconds. Credentials and applications reconcile after failover through a written playbook
- Disaster recovery works only if it is exercised, so colos are drained on a schedule