Pipeline model

A pipeline is an ordered set of components applied to supported database traffic.

Illustrative 0.2.0 flow using reconciled kinds. It is not a recommended default policy: validate component order, limits, field paths, and failure behavior against your own workload.

Diagram resources: Open the SVG full screen · Download the editable Excalidraw source

Processing model

1. Nexo receives a protocol message.
2. Components inspect or transform the message according to their configuration.
3. A component may allow, modify, reject, or record an outcome.
4. Processing continues in order unless a component terminates it.
5. The final message is forwarded upstream when permitted.

Response-side behavior depends on the selected components.

Worked example

The diagram follows one policy-controlled find operation:

1. Ingress decodes the MongoDB wire message and selects the active validated NexoPipeline revision.
2. NexoFilter allows or rejects the operation using configured policy.
3. NexoRateLimit applies the request budget.
4. NexoRewrite optionally normalizes eligible request content.
5. Egress sends the request to NexoProxy.spec.targetAddress. The 0.2.0 runtime renders router and connection fields but does not execute those phases.
6. On the response path, NexoPIIMasking and an optional rewrite run before NexoLogger, NexoAudit, and NexoMetrics record configured outcomes.

All named kinds above are registered by the chart-pinned Operator build 20260611.352-008260c. The six schema-only kinds are intentionally absent.

:::warning Audit payload handling

NexoAudit can be configured to capture BSON request bodies. Treat audit files, stdout, and webhook sinks as sensitive data. Configure redaction, minimize payload capture, and verify representative output before enabling it in production.

:::

Ordering matters

A guard cannot evaluate a transformation that runs later, and a rejected request cannot reach later components. Keep pipelines short, state the intended order, and test representative reads, writes, errors, and administrative commands.

Revisions

Treat every published pipeline as a versioned release:

• review the diff;
• validate in a test environment;
• publish;
• confirm the active revision;
• retain a known-good revision for rollback.

Only use components documented for your protocol and product version.