minimal production load
Production remains focused on saving and retrieving the data users work with in darwin.Cloud.
darwin.Cloud performance
notifications without production drag
darwin.Cloud detects notification events through a SQL Replica, generates email and SMS messages with Kafka and a dedicated queue processor, and stores them on separate hardware before delivery.
darwin.Cloud notification flow
record change
production data saved
SQL Replica
read-optimized copy
notification SQL job
active schedules only
Kafka + queue processor
generate email or SMS
dedicated queue table
separate NVMe storage
sender service
deliver + log status
separate notification work from daily operations
The architecture moves record searching, message generation, queue storage, and delivery away from the production SQL systems that drive active user work.
precise message generation
Dedicated services calculate eligibility, assemble merge fields, and generate email or SMS content.
reliable delivery
Queue storage and delivery-status logging support controlled sending and troubleshooting.
isolated notification pipeline
from data change to delivered message
Each responsibility runs on infrastructure suited to the work, limiting production to core data operations.
- 01
record changes replicate out
Production records modifications and sends the updated data to an Always On SQL Replica on separate hardware.
- 02
a focused SQL job finds eligible records
A job on a separate SQL server evaluates only tables with active notification schedules and searches for relevant create, modified, or post dates.
- 03
the queue processor reads the replica
Stored procedures retrieve modified records and required merge fields from the SQL Replica instead of production.
- 04
Kafka generates messages asynchronously
The dedicated queue processor launches Kafka work to build HTML email or SMS content for each record meeting notification criteria.
- 05
dedicated queue storage holds messages
Generated content and relevant metadata are saved in queue tables on separate storage, such as NVMe drives on a distinct SQL Server.
- 06
a lightweight service sends and logs
The sender service pulls queued messages, delivers them through an email API or SMS gateway, and records delivery status for reporting and troubleshooting.
controls for accurate, single delivery
The queue logic is structured around replica timing, message uniqueness, and complete reporting data.
- Kafka jobs are configured not to retry in ways that could create multiple deliveries of the same message.
- Stored procedures account for the slight synchronization delay in the SQL Replica so notifications are neither missed nor sent twice.
- Agent totals are updated before a notification displaying an agent total is created.
- The search process evaluates the minimum necessary tables and only tables with active notification schedules.
why it matters
streamlined notifications at peak performance
Important record changes can generate precise, reliable messages without diverting the production infrastructure from active brokerage work.
minimal production burden
Production SQL responsibilities stay limited to saving and retrieving the data entered into darwin.Cloud.
efficient SQL Replica use
Read-intensive notification queries run against the replica rather than the production database.
scalable event handling
Kafka provides distributed processing for large volumes of email and SMS change events.
dedicated message storage
Queue tables live on separate hardware so message storage and I/O do not affect production performance.
asynchronous processing
Multi-threaded Kafka work lets the queue processor generate many messages concurrently.
explore connected architecture
Connect notification processing to the security, integration, and cloud systems around it.