We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Core Fundamentals
A communication model where the caller fires off a request and continues without waiting for a response. Essential for non-blocking I/O and event-driven systems.
In short
Asynchronous means a caller sends a request or starts a task and keeps working instead of blocking until the result comes back; the response or completion arrives later through a callback, a future, an event, or a polled status check. It lets one thread or process handle many in-flight operations at once, which is the foundation of non-blocking I/O, event loops, and message-driven systems.
In short
Asynchronous means a caller sends a request or starts a task and keeps working instead of blocking until the result comes back; the response or completion arrives later through a callback, a future, an event, or a polled status check. It lets one thread or process handle many in-flight operations at once, which is the foundation of non-blocking I/O, event loops, and message-driven systems.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Asynchronous across a run of lessons, not one page. These 4 alone are about 77 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Non-blocking concurrent operations that don't wait for each other.
The default replication mode, fast writes at the cost of potential data loss.
Reuse threads instead of creating them, the pattern that makes web servers handle thousands of concurrent connections.
Store large payloads externally and pass a reference through the messaging system instead.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Asynchronous Processingpay once,
yours for life
In a synchronous call, the caller waits. You ask the database for a row, and your code sits on that line doing nothing until the row comes back. The thread is parked, holding memory and a stack frame, contributing nothing while it waits for the network or disk.
Asynchronous flips that. The caller hands off the work and immediately moves on to the next thing. The result is delivered later through some mechanism you set up in advance: a callback function, a promise or future object, an event you subscribe to, or a queue you read from. The key property is that no thread is blocked waiting in between.
This matters because most of what backend systems do is wait. A typical web request spends the vast majority of its time waiting on a database, a cache, an external API, or disk, not running CPU instructions. If every wait blocks a thread, you need one thread per concurrent request, and threads are expensive. Async lets a small number of threads juggle thousands of waiting operations.
At the lowest level, async I/O relies on the operating system telling you when something is ready instead of you blocking on it. Linux exposes epoll, BSD and macOS expose kqueue, and Windows exposes IOCP. Your program registers interest in many file descriptors or sockets, then makes one call that returns the subset that now have data ready to read or space ready to write.
On top of that sits an event loop. It is a single thread running a tight cycle: ask the OS which operations are ready, run the small piece of code (the callback) attached to each one, then loop again. Node.js, Python asyncio, and the Netty framework in Java all work this way. Because each callback runs to completion quickly and never blocks, one loop can service tens of thousands of connections.
Languages dress this up differently. JavaScript uses promises and async/await. Python uses coroutines with async/await driven by an event loop. Go uses goroutines and channels, where the runtime scheduler multiplexes thousands of lightweight goroutines onto a few OS threads and parks the ones that are waiting. In every case the trick is the same: when code would block, it yields control so the underlying scheduler can run something else.
A separate flavor of async is message-driven. Instead of a callback in the same process, the producer writes a message to a broker like Kafka or RabbitMQ and returns. A consumer picks it up seconds or minutes later. The two sides are fully decoupled in time, which is why this style is the backbone of event-driven architectures.
Reach for async when work is I/O bound and concurrency is high: an API gateway fanning out to many services, a chat server holding many open WebSocket connections, a crawler fetching thousands of URLs, or any pipeline where the natural answer is do this later. It also fits work that genuinely should not block the user, like sending a confirmation email, generating a thumbnail, or charging a card through a slow third party.
The cost is complexity. Asynchronous code is harder to read and reason about because the flow is no longer top to bottom. Errors propagate through callbacks or rejected promises instead of a normal stack trace, so debugging is harder and stack traces are often useless. You also inherit new failure modes: a message can be delivered twice, arrive out of order, or get stuck, so async systems usually need idempotency, retries, and dead-letter queues.
Async does not make CPU-bound work faster. If a request spends its time hashing passwords or resizing images on the CPU, an event loop will stall because a long synchronous callback freezes everything behind it. For that you need real parallelism across cores, which is why Node.js apps offload heavy compute to worker threads. The honest rule is that async buys you concurrency cheaply, not raw speed, and only for work that waits.
Picture an e-commerce checkout. The synchronous version does everything in one request: charge the card, write the order, decrement inventory, send the receipt email, update the analytics warehouse, then return the page. If the email provider is slow, the customer stares at a spinner for three seconds for something they do not even need yet.
The asynchronous version does only what must be confirmed synchronously, charging the card and writing the order, then returns success in well under a second. It publishes an OrderPlaced event to a queue. Separate consumers pick that up to send the email, update inventory, and feed analytics, each at its own pace and retried on failure.
This is exactly how large platforms run. Amazon, Uber, and most modern checkout flows confirm the critical path inline and push everything else onto message brokers. The user sees a fast response, each downstream job can fail and retry without breaking the others, and you can scale the email workers independently from the order workers.
Node.js
Its single-threaded event loop built on libuv handles thousands of concurrent connections by running non-blocking callbacks instead of one thread per request.
Apache Kafka
Producers write events and return immediately while consumers process them later, decoupling services in time across high-throughput pipelines.
RabbitMQ
A message broker that lets a service hand off work to a queue and continue, with consumers acknowledging, retrying, or dead-lettering messages asynchronously.
Go
Goroutines and channels let the runtime scheduler multiplex thousands of lightweight tasks onto a few OS threads, parking the ones that are waiting on I/O.
They solve different problems. Async lets one thread handle many waiting operations by never blocking, ideal for I/O-bound work. Multithreading runs code on several threads, often across CPU cores, and is what you need for CPU-bound work. You can combine them: Go and modern runtimes run an async scheduler on top of a pool of threads.
No. Async improves throughput and concurrency for work that waits on I/O, so a server serves more requests with fewer threads. It does not speed up a single CPU-bound task, and for simple low-traffic code it just adds complexity for no gain.
Non-blocking means a call returns immediately instead of parking the thread until the operation finishes. Asynchronous programming is built on non-blocking calls; you issue a non-blocking read, get told later when data is ready, and run your callback then.
async/await is syntax that makes asynchronous code read like synchronous top-to-bottom code. Under the hood await yields control back to the event loop while waiting, so other work runs, then resumes your function when the awaited result is ready. It is sugar over promises and coroutines, not a new mechanism.
Harder debugging because stack traces break across callbacks, plus delivery hazards in message-driven systems: duplicate delivery, out-of-order arrival, and stuck messages. Mitigate with idempotent handlers, retries with backoff, and dead-letter queues for messages that keep failing.
Synchronous
A communication model where the caller waits for the operation to complete before moving on. Simpler to reason about but blocks the thread.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.
This page explains the idea. The "Asynchronous Processing" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Asynchronous Processing lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Asynchronous in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
