Backpressure & Flow Control

When a consumer cannot keep up, the system slows producers or sheds non-critical load instead of dropping safety-relevant events.

Load is bursty

A breeder disruption or a burner plug-instability transient emits orders of magnitude more events per second than steady operation. Layer 4 is designed so that a slow or failed consumer degrades predictably. The log absorbs bursts; consumers pull at their own rate; and lag is a first-class, monitored quantity.

Pull, not push

Consumers pull from committed offsets. A consumer that falls behind simply reads older offsets; it never forces the producer to block on it directly. This decouples fast diagnostic producers on the breeder from slower analytics consumers. The pressure signal is consumer lag = latest offset minus committed offset.

lag = end_offset(partition) - committed_offset(partition)
if lag > LAG_CRITICAL:
    scheduler.pause_low_priority_campaigns()   # shed non-safety load
    alert("L4 consumer lag critical", partition, lag)
elif lag > LAG_WARN:
    ratelimit.tighten(producer_class="analytics")

Load shedding priority

• Never shed: safety-envelope checks, interlock events, command acknowledgements.
• Shed last: live twin inputs needed for the current shot.
• Shed first: post-hoc analytics, non-urgent copilot exploratory proposals, dashboards.

Separation from real-time control

Crucially, L1 real-time control on both machines does not sit behind the event log. If L4 experiences backpressure, the microsecond control loops keep running on their deterministic path and the interlocks remain armed. Backpressure degrades coordination and record-keeping latency, never the machine's own protective reflexes. See interlock integration.

Rate limits on actuation are a separate, harder guard: even with plenty of throughput, the actuation rate limiter caps how fast setpoints may change to stay within engineering slew limits on breeder coils and burner plug magnets.