Kafka events carry stable IDs, type, correlation ID, channel permissions, and safe display data—not passwords, sessions, email addresses, or action tokens.
01 / Overview
Notifications are a system of record, not a side effect.
Financial applications cannot treat email as an afterthought. A lost reset notification creates a support burden; a duplicated security alert erodes trust; an exposed action token becomes a security incident.
VectaSinq separates notification delivery from LeCore’s banking and identity decisions. It owns templates, recipient preferences, channel selection, delivery attempts, retries, and history—without reading or writing LeCore databases.
02 / Design goals
Deliver safely, recover visibly.
Idempotent intake, persisted request state, SMTP attempts, bounded retry, and dead-letter records make message handling inspectable.
Angular operations screens and Grafana telemetry turn delivery health, failures, and lag into evidence a support team can act on.
03 / Architecture
LeCore decides. VectaSinq delivers.
LeCore Identity
decisions + tokens
safe event
decisions + tokens
Kafka
versioned contract
idempotent intake
versioned contract
VectaSinq
templates + delivery
SMTP
templates + delivery
Email provider
SendGrid (locally + prod)
SendGrid (locally + prod)
PostgreSQLRedisOpenTelemetryPrometheus + Grafana
LeCore synchronizes the necessary recipient address through an authenticated internal API. For reset and verification messages, VectaSinq fetches a one-time action URL from LeCore only while rendering; the URL is never persisted in VectaSinq.
07 / Integrations
One delivery boundary across the platform ecosystem.
LeCore identity, gateway, customer, account, payment, and ledger services publish versioned notification requests through Kafka outboxes. Identity-service synchronizes recipient addresses and resolves short-lived action links only while an email is rendered.
Einhaltung is LeCore’s separate compliance and AML platform. It consumes approved LeCore events through its own gateway and compliance services; VectaSinq remains the communication boundary and does not read Einhaltung or LeCore databases.
PostgreSQL stores templates and delivery state, Kafka carries safe events, MailHog supports local inspection, SendGrid provides production email, and Prometheus, Grafana, Jaeger, and OpenTelemetry provide operational evidence.
08 / End-to-end notification flow
Every channel starts with a safe, traceable event.
- 1LeCore writes the identity change, recipient-sync work, and safe notification request to its transactional outbox.
- 2Recipient sync securely upserts the address into VectaSinq; the outbox publishes only after that succeeds.
-
3VectaSinq deduplicates the Kafka
eventId, selects the active email template, and persists a delivery request. -
4For verification or reset, VectaSinq resolves an opaque
correlationIdwith LeCore at render time. - 5LeCore generates and hashes a short-lived token; VectaSinq uses the returned URL only in memory for the outgoing email.
- 6Delivery attempts are persisted. Transient failure retries; terminal failure is retained and emitted as a dead-letter event.
-
7For profile completion and KYC, customer-service emits
customer.profile_updated,customer.kyc_submitted, andcustomer.kyc_approvedto both permitted channels. Administrator approval resolves the target customer’s stable identity before its outbox record is written. - 8The customer inbox is scoped to the authenticated LeCore user; delivery status, retries, dead letters, and lag are visible to authorized operations users in the dashboard and telemetry.
05 / Security
Identity stays with identity.
LeCore owns account status, session validation, password changes, action-token issuance, expiry, and consumption.
VectaSinq owns only messaging data and validates LeCore sessions for its operations API.
Internal recipient sync and action-link calls have distinct service authentication boundaries.
The Angular operations dashboard requires an OPS_ADMIN LeCore session; Grafana remains an engineering-only surface.
09 / Observability
Delivery you can explain.
Actuator metrics, OpenTelemetry traces, Prometheus, Grafana, and Jaeger provide operational visibility. MailHog supports local inspection without exposing real recipients.
The Angular dashboard presents safe delivery aggregates, retry and dead-letter counts, recent status, and access-controlled operational context for demos and support workflows.
10 / Current and planned features
Expand VectaSinq deliberately.
The platform’s current vertical slice is operational; planned extensions preserve the same safe event and delivery boundaries.
In-app notifications
Persistent customer notifications with unread counts, read state, authenticated user scoping, email templates, and in-app delivery.
Versioned templates
Active email templates are seeded and versioned by notification type, with safe variable validation and channel-aware rendering.
Transactional outboxes
Identity, account, payment, ledger, and customer services persist notification events with their business changes before Kafka relay.
Recovery and evidence
Intake mappings, delivery attempts, exponential retry, dead-letter records, provider evidence, and operational metrics make failures explainable.
SMS, push & WhatsApp
Provider adapters with channel policy, consent, and provider-specific delivery evidence.
Preferences
Opt-in/out controls, quiet hours, suppression rules, and an encrypted recipient directory.
Rate limits
Redis-backed per-recipient and per-channel limits to prevent alert fatigue and provider overload.
Retry & dead-letter operations
Configurable backoff, replay tooling, reason codes, and operations runbooks for failed delivery.
Analytics
Channel success rates, delivery latency, engagement, and tenant-level operational reporting.
Outcome
A messaging platform that respects the boundary around money and identity.
VectaSinq demonstrates that customer communication can be distributed, observable, and failure-aware without broadening the attack surface of the banking core.