ARCH-7 Tech Due Diligence

Tech Due Diligence ARCH-7: Asynchronous Processing and Event Architecture

What This Control Requires

The assessor evaluates the use of asynchronous processing patterns, message queues, event-driven architecture, and background job systems, including their reliability, monitoring, and error handling capabilities.

In Plain Language

Any application that tries to do everything synchronously within an HTTP request will eventually hit a wall. Email delivery, report generation, webhook dispatch, data processing - these operations need to happen in the background if you want responsive APIs and a system that scales.

Assessors look at what message broker or queue system you use (Redis, RabbitMQ, SQS, Kafka), how jobs are defined and processed, how failures are handled (retries, dead-letter queues, alerting), whether job processing is idempotent (safe to retry without duplicate side effects), and whether you have visibility into queue depths, processing rates, and failure rates.

Weak async architecture shows up as slow API responses, silently lost background jobs, invisible queue backlogs, and impossible-to-debug processing failures. These problems get worse as volume increases, so assessors want to see that async processing is treated as a first-class concern rather than an afterthought.

How to Implement

Start by identifying all operations that belong in async processing. Common candidates include email and notification delivery, file processing and report generation, third-party API calls and webhook delivery, data synchronisation between systems, search index updates, and analytics event processing.

Choose a message broker that fits your needs. Redis with Bull/BullMQ works well for moderate volumes. RabbitMQ provides robust messaging with routing capabilities. AWS SQS/SNS gives you a managed option with built-in reliability. Apache Kafka suits high-volume event streaming scenarios. Document the choice and your reasoning.

Design every job for idempotency. Jobs must be safe to execute multiple times without causing duplicate side effects. This matters because retries, at-least-once delivery, and queue reprocessing can all trigger duplicate execution. Use idempotency keys, check-before-write patterns, and database transactions to guarantee safety.

Build comprehensive error handling into your async pipeline: automatic retries with exponential backoff for transient failures, dead-letter queues for jobs that exceed retry limits, alerting when dead-letter queue depth crosses thresholds, and tooling for manual review and reprocessing of failed jobs.

Monitor async processing health with key metrics: queue depth (backlog), processing rate (jobs per second), failure rate, average processing time, and dead-letter queue depth. Set alerts for abnormal values that point to processing problems.

Make sure job processing scales horizontally. Multiple worker processes should consume from the same queue without conflicts. Use distributed locking where needed to prevent duplicate processing.

Provide a job dashboard showing recent jobs, their status, and error details. This gives your team the visibility they need for efficient debugging and support.

Evidence Your Auditor Will Request

Message broker architecture and configuration documentation
Job design documentation showing idempotency patterns
Error handling and retry strategy documentation
Queue monitoring dashboard with key metrics
Dead-letter queue management procedures

Common Mistakes

Synchronous processing of operations that should be async, blocking request handling
Jobs are not idempotent; retries cause duplicate emails, charges, or notifications
No monitoring of queue health; backlogs grow undetected until users notice delays
Dead-letter queue not monitored; failed jobs silently accumulate
No mechanism for reprocessing failed jobs; data inconsistencies accumulate

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	CC7.2	Related

Frequently Asked Questions

Do we need Kafka or is Redis/SQS sufficient?

For most SaaS applications, Redis-based queues (Bull, Sidekiq) or SQS are more than enough. Kafka makes sense when you need event streaming, replay capabilities, or genuinely high throughput in the millions of events per second. Picking Kafka for a simple job queue is over-engineering, and assessors will recognise that just as readily as they would recognise an under-engineered solution.

How should we handle jobs that consistently fail?

After exhausting retries, route failed jobs to a dead-letter queue. Alert the team when DLQ depth increases. Provide tooling for inspecting, modifying, and replaying DLQ items. The important thing is to investigate and fix the root cause rather than just blindly replaying. Track DLQ resolution as an operational metric so it does not become a blind spot.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment