Why async processing decouples systems in HLD - Design It to Understand It

Design: Async Processing Decoupling Example

Design focuses on illustrating how asynchronous processing decouples two systems. It excludes detailed UI or database schema design beyond messaging and state tracking.

Functional Requirements

FR1: Allow two systems to communicate without waiting for each other

FR2: Ensure messages are reliably delivered even if one system is slow or down

FR3: Support scaling of each system independently

FR4: Handle failures gracefully without losing data

Non-Functional Requirements

NFR1: Must handle up to 10,000 messages per second

NFR2: Message delivery latency p99 under 500ms

NFR3: System availability target 99.9%

NFR4: Support eventual consistency between systems

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Message queue or broker

Producer system sending messages

Consumer system processing messages

Acknowledgment and retry mechanisms

Monitoring and alerting

Design Patterns

Message queue pattern

Event-driven architecture

Publish-subscribe pattern

Retry and dead-letter queue

Circuit breaker for fault tolerance

Reference Architecture

Message Queue

↓

Message Queue

Components

Producer System

Any application technology (e.g., Java, Python)

Sends messages asynchronously to the queue without waiting for consumer

Message Queue

RabbitMQ / Kafka / AWS SQS

Stores messages reliably, decouples producer and consumer, supports retries

Consumer System

Any application technology

Processes messages independently at its own pace

Acknowledgment Mechanism

Built-in queue ack or custom logic

Ensures messages are processed successfully or retried

Monitoring & Alerting

Prometheus, Grafana, CloudWatch

Tracks message queue health, processing delays, failures

Request Flow

1. Producer creates a message and sends it to the message queue asynchronously.

2. Message queue stores the message reliably and acknowledges receipt to producer immediately.

3. Consumer polls or subscribes to the queue and receives messages at its own pace.

4. Consumer processes the message and sends acknowledgment back to the queue.

5. If processing fails, message is retried or moved to dead-letter queue for later inspection.

6. Producer and consumer operate independently, so producer is not blocked by consumer speed or failures.

Database Schema

Not applicable as this design focuses on messaging decoupling. Message queue stores messages internally with metadata like message ID, timestamp, status, and retry count.

Scaling Discussion

Bottlenecks

Message queue throughput limits when message volume grows

Consumer processing speed bottleneck if messages accumulate

Producer overload if message generation spikes

Message ordering and duplication issues at scale

Solutions

Use partitioned or sharded message queues to increase throughput

Scale consumers horizontally to process messages in parallel

Implement backpressure or rate limiting on producers

Use message keys and idempotent consumers to handle ordering and duplicates

Interview Tips

Time: Spend 10 minutes understanding async benefits and clarifying requirements, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and failure handling, 5 minutes summarizing.

Explain how async decouples systems by removing direct waiting dependencies

Describe message queue role in reliability and buffering

Highlight independent scaling of producer and consumer

Discuss failure handling with retries and dead-letter queues

Mention monitoring importance for operational health