BSFG Enterprise IDMZ Plant Topology

Audience: Solution architects, infrastructure engineers. Use: Apply the reference three-zone topology and placement model for BSFG deployments.

Reference Topology

The canonical BSFG deployment spans three zones connected by firewalled boundaries. This topology is suitable for industrial plants with enterprise IT, an industrial DMZ (IDMZ), and one or more operational technology (OT) zones.

Zone Definitions

A zone is a trust and operational boundary. Each zone has:

A BSFG node (service + JetStream domain + object store)
Producers and consumers (applications, systems)
Zone-local durability (JetStream, object store, databases)

Three-Zone Model (Recommended)

┌─────────────┐          ┌──────────┐          ┌─────────────┐
│ ENTERPRISE  │          │  IDMZ    │          │   PLANT A   │
│   (IT)      │ ←→ BSFG ←→   ←→ BSFG ←→        │    (OT)     │
│             │          │          │          │             │
├─────────────┤          ├──────────┤          ├─────────────┤
│ BSFG Node   │          │BSFG Node │          │ BSFG Node   │
│ JetStream A │          │JetStream │          │JetStream C  │
│ ObjStore A  │          │ObjStore  │          │ObjStore C   │
│             │          │(compact) │          │             │
│ Apps        │          │          │          │ PLC         │
│ Integrators │          │ Gateway  │          │ Historian   │
│ Cloud APIs  │          │          │          │             │
└─────────────┘          └──────────┘          └─────────────┘

Zone Characteristics

Zone	Purpose	Network	JetStream	Object Store
Enterprise	Corporate IT, ERP, cloud integrations, analytics, reporting. Represents the "outside world" from OT perspective.	Internet-connected, cloud-capable	Large capacity, high availability, multi-node cluster	S3, object storage (10+ TB), retention: 10 years
IDMZ	Mediation layer. Decouples IT and OT as an independently operated zone. When used in the canonical three-zone model, IDMZ hosts its own BSFG node and zone-owned durability substrate for facts and artifacts that must transit through the mediation layer.	Firewalled both sides, no internet access	Small footprint, single-node or HA pair, zone-local retention	Compact zone-local object store, retention per deployment policy
Plant A (OT)	Operational equipment, PLCs, historians, quality systems, batch records. Represents the "plant floor" from IT perspective.	Closed network, no internet, air-gapped from IT	Single or dual-node, high durability (replicated or WAL-based)	Local storage or NAS (1–5 TB), retention: 3–7 years, retention policy per bucket (batch-files: 10y, alarms: 1y)

BSFG Node Placement

Each zone has exactly one BSFG node (or a HA pair). The node is the gateway for all cross-zone fact exchange.

Enterprise Zone BSFG Node

Producers/Consumers (local apps)
           ↓
      BSFG Node
           ↓
      JetStream Cluster
        (3-node HA)
           ↓
      Object Store (S3 or equivalent)
           ↓
      ↔ IDMZ boundary (mTLS + Connect RPC)

Enterprise is often the "hub." It receives facts from both IDMZ and Plant, and sends facts to both.

IDMZ BSFG Node

      ↔ Enterprise boundary (mTLS + Connect RPC)
           ↓
      BSFG Node
           ↓
       JetStream (small footprint, zone-owned)
           ↓
       Object Store (compact, zone-owned)
           ↓
      ↔ Plant boundary (mTLS + Connect RPC)

IDMZ is a real zone in this topology. It may retain facts and artifacts under its own operational policy, while still preserving the BSFG rule that durable state is zone-owned and never lives in the boundary network itself.

Plant Zone BSFG Node

Producers/Consumers (PLC, historian, batch system)
           ↓
      BSFG Node
           ↓
      JetStream (high durability, possibly dual-node)
           ↓
      Object Store (NAS or local SSD, zone-owned)
           ↓
      ↔ IDMZ boundary (mTLS + Connect RPC)

Plant is the edge. It operates autonomously when the IDMZ or Enterprise is unreachable.

BSFG Peer Connectivity

Peer communication occurs over mTLS + Connect RPC. Each BSFG node may need to initiate or accept connections:

Enterprise ↔ IDMZ

Enterprise BSFG calls IDMZ BSFG: `AppendFact`, `FetchFacts`, `ConfirmReceipt`, `PutObject`
IDMZ BSFG calls Enterprise BSFG: `AppendFact`, `FetchFacts`, `ConfirmReceipt`, `PutObject`
Both directions are potential; consider which zone initiates (pull vs push architecture)

IDMZ ↔ Plant

Similar bidirectional peer model

Enterprise ↔ Plant (Optional Direct)

Possible but not recommended in production (IDMZ should mediate)
May be useful for high-throughput scenarios or to bypass IDMZ latency
Requires direct firewall rules; adds operational complexity

Multi-Plant Scaling

If multiple plants exist, the topology expands:

Enterprise
    ↓
  IDMZ
    ↓
 /  |  \
Plant A  Plant B  Plant C

Each plant zone is independent. Cross-plant communication goes through Enterprise or IDMZ (not direct).

Reference Deployment: Enterprise + IDMZ + 2 Plants

This document describes the general topology principles. For a detailed, production-ready reference deployment, see the Reference Deployment: Enterprise + IDMZ + 2 Plants document.

That document provides:

Specific IP addresses, hostnames, and certificate CNs
Complete firewall rules with source/dest/port specifications
JetStream domain configurations for each zone
Object store retention policies by bucket type
Operational responsibility matrix (who owns what)
Detailed deployment checklist (30+ items)
Real-world topology diagram with all components

Use it as the template for Statements of Work (SOW) and deployment planning.

Alternative: 2-Zone Model (Direct IT/OT)

Without IDMZ, Enterprise and Plant zones connect directly. This is simpler but less flexible for complex integrations:

Enterprise ↔ BSFG ↔ Plant

Use this for:

Greenfield deployments with no existing DMZ
Small, co-located IT and OT teams
Single-plant scenarios

No Durable Middleware at Boundary

Critical rule: the boundary network (firewalls, routers, gateways) must not contain durable middleware. This means:

❌ No Kafka broker at IDMZ
❌ No PostgreSQL database at IDMZ
❌ No message queue at IDMZ
✅ Connectivity infrastructure only: routers, firewalls, TLS terminators

BSFG nodes live inside zones (Enterprise, IDMZ, Plant), not at the boundary. They reach across the boundary via mTLS RPC calls.

Cross-Zone Synchronization

Cross-zone fact flow is always explicit and traceable:

Zone A Producer → Zone A BSFG → Zone B BSFG → Zone B Consumer
                     |               |
                 (AppendFact)    (FetchFacts)
                                (ConfirmReceipt)

No implicit shared state, no database replication, no message broker mirroring. Facts move one at a time, with explicit confirmation.

Firewall and Network Policy

See Network Policy for detailed firewall rules.

Deployment Checklist

☐ Provision three zones (or two for simplified model)
☐ Install one BSFG node per zone
☐ Configure zone-local JetStream domain for each BSFG node
☐ Configure zone-local object store (S3, NAS, or equivalent)
☐ Generate mTLS certificates for each BSFG node (zone identity)
☐ Configure firewall rules to allow BSFG peer communication
☐ Test connectivity between zones (RPC health checks)
☐ Deploy producers and consumers in their respective zones
☐ Configure cursor tracking and durable consumer names
☐ Set up monitoring (replication lag, cursor position, backlog)

← Back: Message Catalog Framework Next: Reference Deployment Topology →