Skip to content

Armored Carrier — Parallel Processing Cluster

A complete, turnkey pipeline for complex orchestration that automatically dispatches parallel tasks and aggregates the results, all within a sealed Zero Trust environment.

Tags: Armored Car | Single Cluster | HTTP1/REST | 6 Pods

Overview

The Armored Carrier (Parallel Processing Cluster) implements a full scatter/gather pattern across six pods. A Gateway/Initiator (http-gateway) triggers the network; a Distributor/Router (http-fan-out) broadcasts to two Relay/Processor pods (http-relay); an Aggregator (http-fan-in) collects both results; a Sink/Terminator (http-sink) delivers the final output.

All six pods run Armored Car mode (xtra7) with per-request key rotation on every hop.

flowchart TD
    A["Gateway / Initiator\n(http-gateway)"]
    B["Distributor / Router\n(http-fan-out)"]
    C["Relay / Processor\n(http-relay)\nprocessor-a"]
    D["Relay / Processor\n(http-relay)\nprocessor-b"]
    E["Aggregator\n(http-fan-in)"]
    F["Sink / Terminator\n(http-sink)"]
    A -->|"WoSP xtra7"| B
    B -->|"WoSP xtra7"| C
    B -->|"WoSP xtra7"| D
    C -->|"WoSP xtra7"| E
    D -->|"WoSP xtra7"| E
    E -->|"WoSP xtra7"| F

Use Cases

  • Map-reduce patterns inside a Zero Trust network
  • Parallel task dispatch with result aggregation (e.g., multi-model inference, parallel API calls)
  • Orchestration pipelines where a coordinator dispatches N workers and waits for all results
  • Complex data processing where independent stages run concurrently

Bundle Contents

armored-carrier-parallel/
├── gateway/          ← http-gateway (boundary)
├── distributor/      ← http-fan-out (internal)
├── processor-a/      ← http-relay (internal)
├── processor-b/      ← http-relay (internal)
├── aggregator/       ← http-fan-in (internal, INGRESS_COUNT=2)
├── sink/             ← http-sink (boundary)
├── deploy.sh
├── teardown.sh
├── pinhole-setup.sh
├── blueprint.yaml
├── README.md
└── EULA.md

Deploy

Prerequisites: Docker Desktop, k3d >= 5.0, kubectl, valid Hopr license

for pod in gateway distributor processor-a processor-b aggregator sink; do
  cd ${pod}/app/ && docker build -t serial-app-wosp-node:latest . && k3d image import serial-app-wosp-node:latest
  cd ../..
done
bash deploy.sh

bash deploy.sh

See Build, Package, and Deploy.

Verify

kubectl logs -n armored-carrier-parallel-gateway-ns \
  deployment/gateway -c web-app -f

Expected output:

🔁 Auto-trigger starting — sending 5 messages
🔁 Auto-trigger complete — 5/5 messages sent.

Confirm aggregated results at the sink:

kubectl port-forward -n armored-carrier-parallel-sink-ns deployment/sink 8000:8000
curl http://localhost:8000/output

Expected: {"count": 5, "results": [...]}. Each result contains combined output from both processors.

Customize

Hook functions for this blueprint:

  • on_trigger(payload, headers) — in gateway/app/app.py: initial validation and task definition
  • on_receive_fan_out(payload) — in distributor/app/app.py: task routing logic
  • on_receive_relay(payload) — in processor-a/app/app.py and processor-b/app/app.py: parallel task execution
  • on_aggregate(partials) — in aggregator/app/app.py: merge the two processor results
  • on_receive_terminator(payload) — in sink/app/app.py: final output handling

See Hook Functions Reference.

Pricing

6 WoSP units (1 per pod). See Commercial Licensing.