Triggers (outlet → Lambda)
Triggers tell AWS Lambda that new outlet activity may be available. They are a control-flow hook, not a second channel for the same change data your applications already read from the outlet.
When the product publishes on a bound outlet version, the platform can invoke your function so you react elsewhere (integrate, notify, fan-out, start a job). The outlet data for normal consumption is still obtained the same way as without a trigger: open an outlet connection, poll the stream, and advance offsets as in Outlets. That poll-based read path is what clients use in production: it is more performant for reading the stream and it carries the ordering guarantees the platform defines for outlet delivery.
This page is not about a JoinTrigger in Spine (the type used in join and lookup flows). Here, “triggers” means Lambda invocations driven by outlet activity, configured per application in the control plane.
Control flow versus data flow
| Control flow (triggers) | Data flow (outlets) | |
|---|---|---|
| Purpose | Signal that new work may exist so your Lambda can react—side effects, orchestration, waking other systems. | Deliver typed per-key changes to consumers with offset-based reads. |
| Mechanism | Invoke your function with context about which outlet versions the round concerns. | Long-lived bidirectional connection and poll rounds on the outlet service; new messages are delivered on the stream as they become available during an active poll (see Outlets). |
| Role in your architecture | A nudge: “there may be something to process.” Not a parallel copy of the outlet log for primary consumption. | The path you use to read outlet data efficiently, with the platform’s ordering guarantees for that stream. |
Triggers do not replace outlet consumption. Readers that need the actual change payloads should use the same outlet connection and poll loop as in the untriggered case; that approach is both more performant for bulk reads and the one that upholds the intended ordering constraints for the outlet stream.
What you configure
- Lambda function — The ARN of the function to run.
- Invoke access — An IAM role in your AWS account that the platform may assume to invoke that function. You control trust and permissions; the platform only calls the function using that delegation.
- Bindings — Which outlet versions this trigger follows. Use the outlet versions your deployment actually runs (see Outlets for how versions evolve over time).
- Operational tuning (optional) — Retries and timing when an invocation fails or does not advance processing, so work eventually completes without overwhelming a broken handler. Your admin UI or API shows the exact fields.
- Tags (optional) — Metadata such as environment or owner, for governance and operations.
How it behaves
- The platform watches bound outlet versions and invokes your Lambda as a control signal: new data may be available to process in other systems. When a stream is quiet, occasional checks can still run so the signal path does not stall on edge-case timing.
- Failed invocations or rounds that do not make progress are retried with backoff. Make your handler idempotent where you can: expect at-least-once behavior in practice.
- If you change which outlet versions are bound, processing moves to the new set; exact behavior follows the control plane API and your team’s runbook.
Do not treat Lambda as the primary way to deliver the outlet message stream to application consumers—use a normal outlet client and poll loop for that. The invocation carries context (including which outlet versions the round concerns) for side effects; your function might also start a job that then opens a standard outlet read. Payload shape and fields depend on your product’s contract; see the control plane and client documentation for your environment.
How to set it up and manage
Triggers are scoped to a data product application. Organization admins create, update, and delete triggers and bind or unbind outlet versions through the control plane: APIs, client libraries where your language ships them, or the operator CLI your environment provides—use --help on that tool for subcommand names in your release. Some environments also expose these operations through MCP for agent-driven workflows.
When a trigger is created, the control plane assigns a server-generated 32-byte nonce. Lambda invocations use this nonce encoded as base64url without padding in the OIDC subject:
application:<application-id>:trigger:<trigger-id>:<nonce>
Use the subject returned by create/list operations in the AWS IAM role trust policy that grants Dataspine invoke access. The nonce is known after trigger creation, so the create-time IAM dependency cycle remains until a later reservation API is available.
For health and incidents, combine Observability on the Dataspine side with AWS Lambda metrics and logs in your account.
See also — Outlets · Control plane · Applications · Observability