ADR-0032: Cross-Zone Transfer Is Pull-Driven by the Receiving Zone

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

• 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