Use Case · Product

Notification fanout on the Software Lifecycle Cloud

Notification fanout on KERNSTACK routes one event to every channel it owes — email, project conversation, chat — as steps of a declared workflow: the event names the template and the recipients, workers render and send per channel, and each channel’s receipt lands in a table. “Did the customer get the receipt email?” becomes a query, and changing who gets notified stops being a code change in five places.

Approval WorkflowsContainer WorkersNoSQL TablesCollaboration Board
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Product teams send mail and chat notices from wherever the event happened to occur in code, so the notification logic for one event ends up copied across handlers, each copy drifting: one sends the old template, one forgets the chat copy, and one mails the customer twice when the handler retries. The customer experiences the architecture directly, in their inbox, twice.

Architecture on the Software Lifecycle Cloud

Producers emit an event — kind, subject, template data — and start the notification workflow. Steps fan out per channel: the email worker renders the project’s template, the conversation step posts to the bound topic (mirrored to Telegram or WhatsApp where bound), and each outcome writes a receipt row. Preferences are recipient rows: channels a user muted are skipped by the step that would send, with the skip recorded too.

Receipts end the argument

Every channel attempt leaves a receipt — sent, bounced, skipped-by-preference, failed with the provider’s words. Support stops asking engineering to check the mail vendor’s console, because the answer lives in the same project as the order that triggered it. Template changes are code changes with review dates, so “which wording did customers get in March” is a git question.

  • One event, one workflow run: all channels for an order share a single inspectable history
  • Muted channels record a skip receipt, distinguishing “we chose not to” from “it broke”
  • Templates live with the code; wording changes are reviewed diffs, not vendor-console edits

Channels the platform does not pretend to be

Email delivery itself runs through your sending provider called from the worker — deliverability, domains, and suppression lists remain that provider’s craft. What the project owns is the orchestration and the evidence: which events produced which sends, for whom, with what result.

FAQ

Frequently asked questions

As project files rendered by the sending worker, versioned with the code. A wording change is a reviewed diff with a date, and receipts tie each send to the run that produced it — so template history is auditable, not archaeological.

Yes. Preferences are recipient rows consulted per channel step: email can be muted while chat continues, and the skipped channel records a skip receipt so nobody mistakes preference for failure.

The receipt row: event, channel, recipient, provider response, timestamp. It is written by the sending step in the same table family as the triggering data, so support answers from the project, not from a vendor console.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · OrchestrationWorkflowsDurable workflows with human pausesService · ComputeWorkersContainer workers for long jobsService · DataTablesServerless key-value and document tablesService · PeopleCollaborationBoards and conversations on the projectIndustry SolutionE-commerce Cloud SolutionsE-commerce on KERNSTACK owns the parts of commerce that constitute the business: the catalogue and its search, carts and checkout state, the order lifecycle, raw payment events reconciled into provable order states, and fulfilment workflows with human steps for the exceptions. Cards stay with the payment provider; the data that makes the business worth buying moves onto infrastructure the merchant controls, in Europe.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →