I built a serverless webhook service that delivers real-time conversation events to each NHS trust's own systems, handling encryption, authentication, concurrent delivery, and automatic retries.
A serverless event processing pipeline that delivers real-time conversation
notifications into NHS trust systems. Built as a lightweight, fault-tolerant
microservice, it listens for events on a clinical messaging platform — new
messages, read receipts, conversation closures — and pushes them securely to
each trust's own systems with automatic retries and flexible authentication.
The platform is a clinical communication system used inside NHS trusts. As
trusts adopted it, they needed conversation activity fed into their own
infrastructure — patient management systems, analytics dashboards, internal
tooling — in real time, as events happened.
The challenge
Trusts needed to know the moment something happened in a conversation and
have that information land reliably in their own systems. Every trust had
different security requirements, different endpoints, and different views on
which events mattered. The service had to handle a stream of encrypted
conversation data, deliver to multiple destinations per trust simultaneously,
and keep going when downstream systems were temporarily unavailable — all
inside a tight processing window.
Key requirements:
- Decrypting sensitive conversation data on the fly
- Supporting multiple authentication methods per endpoint
- Delivering to several endpoints at once, each with independent retry logic
- Letting each trust choose which events trigger notifications
- Running across isolated testing, staging and production environments
How it works
Events arrive batched on a stream. The service unpacks each one and decides
what to do based on its type: when a conversation starts, webhook settings
are recorded for later; when something happens within one, it looks up which
endpoints care about that event and begins delivery. Encrypted content is
decrypted in flight, with graceful fallback if decryption fails.
Configuration is held separately from short-lived per-conversation state, so
stable trust settings stay cleanly apart from transient data, and the
transient side expires on its own rather than needing cleanup jobs.
Each endpoint references a named secret holding its credentials, supporting
OAuth2 with token caching, bearer tokens, and basic auth. Trusts can rotate
credentials without any code change.
Delivery runs concurrently across all configured endpoints, each with its own
retry logic and progressive backoff. It stops retrying immediately on
permanent errors but keeps going on transient ones.
What it demonstrates
- Flexible authentication per endpoint, with credentials managed outside
the codebase and rotatable at any time - Smart retries that distinguish between failures worth retrying and
failures that will never succeed - Event filtering so each trust receives only what it asked for
- Encrypted payload handling with environment-aware key management
- Built to keep going — failed records, decryption problems, missing
configuration and delivery failures are all logged without crashing the
service; it processes what it can and moves on
Results
- Concurrent delivery to multiple authenticated endpoints per trust
- Runs across three isolated environments in separate cloud accounts
- Thorough unit and integration test coverage with mocked cloud services
and HTTP calls
Technologies used
Backend: Node.js, ES Modules, serverless functions, stream processing
Data: NoSQL document storage, managed secrets, AES-256 encryption
Networking: Connection pooling, OAuth2 client credentials, exponential backoff
Infrastructure: Infrastructure-as-code, scoped IAM policies, distributed tracing, structured logging
CI/CD: Pipeline deployments with manual gates across multiple accounts
Testing: Jest, cloud-service mocking, HTTP mocking, ESLint