notes

Appearance

Asynchronism ​

In an asynchronous architecture, execution is unblocked. A system can kick off a heavy, time-consuming operation and immediately move on to perform other work, handling the result of that heavy operation whenever it completes in the background. To achieve this in distributed software systems, we rely on specialized components: Task Queues, Message Queues, and architectural throttling mechanisms like Backpressure

Task Queues ​

A Task Queue handles asynchronous execution within an application architecture. It is used to delegate heavy background compute jobs away from the main user-facing application thread so that users experience instantaneous response times.

  • How it works: A user performs an action (e.g., clicking "Export Report" or uploading a profile image). Instead of forcing the web server to process the heavy PDF or resize the image on the spot, the web app creates a descriptive task payload and pushes it into an internal task queue.
  • The Worker Fleet: Dedicated background processes (Workers) continuously pull tasks from this queue and execute them asynchronously.
  • The User Experience: The web server returns an immediate 202 Accepted response. The user can keep browsing the app while the task processes quietly in the background.
  • Common Tools: Celery (Python), BullMQ (Node.js), Sidekiq (Ruby).

Message Queue ​

While a Task Queue is focused on distributing work units to background runners, a Message Queue is an infrastructure layer designed to handle communication between entirely separate services or microservices.

  • How it works: It acts as an asynchronous mailbox. Instead of Service A calling Service B directly via a rigid network call (like HTTP or gRPC), Service A serializes its data into a Message and drops it into a queue channel.
  • Decoupled Architecture: Service A does not know or care when Service B reads the message, what language Service B is written in, or if Service B is currently down for maintenance. The message sits safely inside the broker's storage until a consumer pulls it.
  • Common Tools: RabbitMQ, Apache Kafka, AWS SQS.

Backpressure ​

When you move to an asynchronous architecture using queues, you face a new physical reality: the rate of incoming data can easily exceed the speed of your downstream consumers. If an upstream service drops 50,000 messages per second into a queue, but your background workers can only process 1,000 messages per second, the system will eventually fail. The queue will expand until the broker runs out of RAM or disk space, causing a full-system crash. Backpressure is the feedback mechanism used by a downstream consumer to signal upstream producers to slow down, pause, or throttle their transmission rates before the system chokes.

Strategies to Enforce Backpressure: ​

  • Stop/Pause Signals: The consumer tells the message queue broker to stop sending data packets over the network socket until it finishes processing its current batch.
  • Buffer Limits: Setting a maximum cap on queue sizes. Once the queue is full, the broker applies backpressure up to the web APIs, forcing them to reject incoming client requests with an HTTP 429 Too Many Requests code.
  • Reactive Streams: Implementing protocols where consumers explicitly ask producers for a specific allocation quota (e.g., "Send me exactly 50 items"). The producer cannot emit item 51 until the consumer explicitly requests the next batch.

Idempotent Operations ​

Idempotent operations are operations that can be applied multiple times without changing the result beyond the initial application. In other words, if an operation is idempotent, it will have the same effect whether it is executed once or multiple times. It is also important to understand the benefits of idempotent operations, especially when using message or task queues that do not guarantee exactly once processing. Many queueing systems guarantee at least once message delivery or processing. These systems are not completely synchronized, for instance, across geographic regions, which simplifies some aspects of their implementation or design. Designing the operations that a task queue executes to be idempotent allows one to use a queueing system that has accepted this design trade-off.