Sync vs Async
The most important timing choice in any system that has to do more than one thing at a time.
Synchronous means one thing after another
Synchronous just means "in order." Start a task. Wait for it to finish. Then start the next one. Simple and easy to think about.
Imagine a user submits a checkout form. The server does five things one after the other.
1. Check the payment info. 200 milliseconds. 2. Charge the credit card. 800 milliseconds. 3. Save the order in the database. 50 milliseconds. 4. Send a confirmation email. 1,500 milliseconds. 5. Return the success page to the user.
Total time? 2.55 seconds. And the user has been staring at a loading spinner the whole time.
There is another problem. If step 4 fails because the email service is down, the entire request fails. The user sees an error page even though the order actually went through. That is a real bug just waiting to happen.
Asynchronous means kick it off and move on
Asynchronous is the opposite. You start a task, but you do not wait for it. You move on and let it finish in the background.
Take the same checkout. Now the server does this.
1. Check the payment info. 200 milliseconds. 2. Charge the card. 800 milliseconds. This part still has to wait because we need to know if the payment worked. 3. Save the order. 50 milliseconds. 4. Drop a note into a queue that says "send a confirmation email to [email protected]." 5. Return the success page right away.
Total time? 1.05 seconds. That is less than half what it was before. The user sees the success page quickly and moves on with their life.
Meanwhile, a separate program called a worker is reading from that queue. It picks up the note, sends the email, and retries if it fails. The user never knew the email was sent a few seconds later.
When to pick one over the other
Pick synchronous when:
The user needs the answer right now to keep going. "Is my password correct?" needs an immediate yes or no. The task is fast. Anything under 100 milliseconds is fine to do synchronously. The downstream service almost never fails.
Pick asynchronous when:
The task is slow. Anything over half a second is a good candidate. The user does not need the result immediately. Emails, push notifications, analytics tracking, sending invoices. The downstream service is flaky or sometimes goes down. You want to absorb spikes in traffic. The queue acts as a buffer. You want to retry failed work without making the user wait.
One thing that trips people up. Making a task asynchronous does not make it faster. The email still takes the same amount of time to send. You are just not forcing the user to wait for it.
How async actually works in real systems
The piece of infrastructure that makes async work is called a queue. A queue is just a service that holds messages until somebody picks them up.
Common queue tools include RabbitMQ, AWS SQS, Kafka, and Redis Streams.
The pattern is always the same.
A producer (your web server) drops a message into the queue. The message might say "process this video file" or "send this email" or "recompute the recommendations for user 42."
A worker (a separate program that runs continuously) pulls messages off the queue, one by one. It does the work. If the work fails, it retries.
If a worker crashes while handling a message, the message stays in the queue and another worker picks it up next. Nothing is lost.
We will go much deeper on queues in a later concept. For now, just remember this. Any time something happens "in the background" after you click a button on a website, there is almost certainly a queue and a worker doing it.