CONCEPT Cited by 1 source
Cross-regional attribution via CIDR trie¶
When workloads span multiple cloud regions, cross-regional IP attribution must resolve a remote IP that may belong to a workload in a different region. Two shapes are possible:
- Globally replicate all ownership state to every region.
- Locally resolve the region, then forward the attribution request.
Option 2 is the right shape when cross-regional traffic is a small fraction of all traffic (at Netflix: ~1% of flows) — global replication of high-frequency state across regions is wasteful.
CIDR trie as the dispatch primitive¶
Build a trie keyed on the bits of IPv4/IPv6 addresses, populated with the CIDR ranges of every regional VPC and their region tag. Looking up a remote IP walks the trie in O(address-length) and returns the owning region.
If the region is local, resolve via the in-region ownership map. If remote, forward the flow record to a node in the target region and let it do the lookup; the target region already has in-memory heartbeat state for its own IPs.
Why CIDR trie + forwarding beats global broadcast¶
- Storage: one global CIDR → region trie vs. full per-IP time- range state replicated to every region.
- Bandwidth: forward a small fraction of flows vs. broadcast every heartbeat to every region.
- Availability: cross-region data movement only on the 1% minority; the 99% local case is unaffected by cross-region outages.
- Consistency envelope: per-region ownership maps remain local consistency domains; cross-region lookup inherits whatever consistency the region-local state has.
Seen in¶
- sources/2025-04-08-netflix-how-netflix-accurately-attributes-ebpf-flow-logs — canonical wiki instance; ~1% cross-regional flow fraction cited as the reason broadcast is over-provisioned vs. forward-on-trie.