complete action history
Track who changed data, what changed, when it happened, and how.
darwin.Cloud performance
reliable audit updates, off production
darwin.Cloud uses Kafka, an Always On SQL Replica, and dedicated NVMe-backed storage to process audit-log updates asynchronously—protecting real-time user operations while maintaining complete history.
darwin.Cloud audit update flow
data change
INSERT · UPDATE · DELETE
Kafka topic
background event queue
controlled delay
replica synchronization
SQL Replica read
production duplicate
audit-log server
dedicated NVMe storage
essential history, not a real-time workload
Audit logs are indispensable for transparency and accountability, but they are primarily used for research and reporting after the fact. Updating them directly on production added unnecessary load to active user systems.
compliance and reporting
Preserve the evidence needed for transaction reporting, oversight, and accountability.
post-event research
Support investigation and troubleshooting after financial or sales activity occurs.
Kafka + SQL Replica
an asynchronous path to complete audit history
The pipeline separates event generation, data reads, and audit-log writes across infrastructure designed for each task.
- 01
generate and queue change events
Whenever data is modified through INSERT, UPDATE, or DELETE, production generates an event and sends it to a Kafka topic so the user can continue working.
- 02
process asynchronously with a controlled delay
Kafka queues events in the background and allows time for the SQL Replica to synchronize with the production database.
- 03
read from the SQL Replica
The delayed Kafka consumer retrieves the necessary data from an exact read-only duplicate instead of adding read load to production.
- 04
write to dedicated audit storage
Processed audit entries are stored on a separate server with high-performance NVMe drives for fast, reliable audit-data storage.
why it matters
performance and accountability can scale together
The new approach keeps daily operations responsive while preserving detailed audit records for compliance and analysis.
faster production performance
Processing, storage, and read workloads move away from production so real-time user operations can run without audit-update delay.
efficient resource utilization
The SQL Replica handles read-intensive work while the dedicated audit server handles write-heavy processing and storage.
scalability
Kafka’s distributed architecture supports high volumes of audit events as system activity grows.
timely, reliable audit logs
Delayed updates preserve accurate, complete history for research and reporting without requiring real-time processing.
designed for today and tomorrow
- uncompromised performance for day-to-day operations
- reliable, detailed audit logs for compliance and accountability
- scalable infrastructure designed to grow with activity
explore connected architecture
Connect asynchronous audit updates to their storage, analytics, and security context.
audit-log infrastructure
See the dedicated SQL Server and NVMe architecture that stores audit history.
view detailscube update architecture
Review the parallel Kafka and SQL Replica process for analytics cubes.
view detailssecurity architecture
Explore the broader controls and infrastructure protecting darwin.Cloud.
view details