Context
BSFG already commits to:
- zone-local JetStream domains
- explicit BSFG peer protocol for cross-zone synchronization
- unary paged pull fetch semantics
- durable named consumers for progress tracking
One remaining synchronization question is directional control:
- does the source zone push facts outward when available?
- does the receiving zone pull facts inward on its own schedule?
- or do both patterns coexist as equal primitives?
This choice affects firewall posture, operational autonomy, retry behavior, and whether the receiving zone controls its own intake cadence.
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Source-push replication | Origin zone initiates outbound delivery whenever new facts are available. | lower apparent latency simple producer mental model |
receiving zone loses intake control harder fit for restrictive inbound-only trust postures push retry logic becomes more coupled to source availability |
| Bidirectional symmetric push/pull | Allow both zones to use either push or pull as equal first-class transfer styles. | flexible can optimize for local topology |
two competing mental models harder security and ops discipline weakens architectural clarity |
| Receiver-driven pull (Selected) | Destination zone initiates fetch from the source zone and appends locally after receipt. | receiving zone controls intake rate and timing aligns with unary paged pull and durable consumers fits stricter boundary and firewall postures clear retry and lag semantics |
slightly higher coordination overhead continuous synchronization requires polling cadence |
| Shared scheduler/orchestrator | An external coordinator tells zones when and how to move facts. | centralized control global scheduling policy possible |
adds new control-plane dependency weakens zone autonomy not needed for the boundary primitive itself |
Decision
Cross-zone transfer is pull-driven by the receiving zone.
destination zone
-> FetchFacts from source zone
-> AppendFact into destination log
-> ConfirmReceipt as durable destination commit
This means the receiving zone owns:
- when intake occurs
- how aggressively it polls
- which durable consumer identity tracks progress
- when local durable commit has occurred
The source zone does not push facts as the canonical transfer primitive. It exposes retained history for authorized peers to pull.
Consequences
Benefits:
- zone autonomy is preserved at the intake boundary
- security posture is simpler and more explicit
- fetch, consumer progress, and confirmation semantics align into one model
- backpressure is naturally controlled by the receiver
Tradeoffs:
- near-real-time replication depends on polling cadence rather than push immediacy
- receivers must actively manage sync loops
- operators must reason about lag as a receiver-side operational concern