I have been searching extensively about the difference between synchronous and asynchronous patterns and how this relates to event driven architecture. On its face it is quite obvious, I simply equated asynchronous with Event Driven. But then I came across this quote:

All asynchronous systems are event driven, but not all event driven systems are asynchronous.

This kind of makes sense, if we define synchronous as keeping things in time order. I have also heard other definitions as client and server working with the same "clock", its systems are in "sync". This definition does not make sense to me at all, because no system is actually always in sync. Across the internet, we always have delays and this delay always varies. Hence that seems as a sloppy explanation to me. Thus I fall back to synchronous means "processing in strict time order".

So this made me think that an event driven system can be synchronous if we introduce FIFO queues as our event pattern. That will keep the strict ordering and therefore we have a synchronous event driven pattern.

So, I thought I had it under wraps until I came across this article from Amazon. According to my thought process both these systems are synchronous but Amazon names one synchronous and the other asynchronous. Which led me to this forum, since I trust Amazon documentation more than my own vague reasoning in this context.

TLDR What is a synchronous system? What is an event driven synchronous system?

enter image description here enter image description here

  • 1
    I define "Synchronous" as "Blocking" and Asynchronous as "Non-Blocking." Asynchronous systems still reassemble things in the right order; they just don't block (i.e. make you wait) on any particular step. Mar 29, 2022 at 17:06
  • I like "blocking" more then "operating with the same clock" but how do you explain the above differentiation and what is a synchronous event driven system using the blocking analogy?
    – Frankster
    Mar 29, 2022 at 17:20
  • Presumably the S3 bucket is not being blocked because its requests are queued by the SQS and then fed to the lambda function as it becomes available. Mar 29, 2022 at 17:50
  • Not entirely relevant, but if we ignore the word "system", a lot of GUI libraries are synchronous event-driven things, at least in terms of code the library user writes. My personal experience is with Qt, but other examples surely do exist.
    – jaskij
    Mar 29, 2022 at 21:04

3 Answers 3


In this context, the concept of 'synchronous' essentially means that the event is processed and confirmed by the event consumer before the producer considers the event processed. Here's a simple analogy: suppose you ask for a pair of socks and someone tosses them to you. They might not even look to see if you caught them. Once the socks left their hand, their part of handling the 'event' is done. Now contrast that to someone handing you their newborn. They are going to continue to hold their baby until you have confirmed that you have it safely in your arms. The former is asynchronous, the latter is synchronous.

You are correct that this is not about 'synchronizing' clocks. That's a different kind of thing entirely. It's interesting and essentially leads you to relativity if you think too much about it but it's not necessary to have clocks synchronized in order to have synchronous event processing.

One of the things that I think trips people up with this is that most asynchronous systems are built upon synchronous systems. For example, a distributed messaging system typically doesn't consider a message delivered until the other nodes have confirmed receipt. The distinction is that the message need not be processed.

  • I like this analogy but as a response I now have no idea what an event driven synchronous system is? Keeping up with your example about carefully handing of infants. I guess passing the child to your partner by first putting into a crib, then waiting for your partner to pick it up, represents a producer and a consumer separated by a queue and the producer is free to go off and clean the kitchen. But to circle back to the topic, what in this case defines a synchronous event driven system? If such a thing even exists?
    – Frankster
    Mar 29, 2022 at 17:37
  • I think maybe you should step back and think about what an event is. Let's say I click on a web link that calls a web service and starts a job. That's a kind of event. Now I could get an immediate response saying the job is scheduled and perhaps a link to where I can check on it's status. OR, the web service respond only once the job was complete and show me the results.
    – JimmyJames
    Mar 29, 2022 at 17:45
  • The first example from the AWS article is being called synchronous because the lambda is being executed at the time the event is fired. The second is asynchronous because the lambda is run when the message is pulled from the queue which could be much later after the event occurred.
    – JimmyJames
    Mar 29, 2022 at 17:53
  • Whether something is asynchronous can depend on the level of abstraction. Consider a 3rd version of the AWS example where the S3 event triggers a lambda which writes to SQS for another lambda to execute. Even though each step is more or less synchronous, at a high-level it's async. Or consider that TCP (synchronous) is built upon UDP (asynchronous). It's a bit of a turtles all the way down type of thing.
    – JimmyJames
    Mar 29, 2022 at 18:00

It's not about delays. It's about if the sender of an event can move on to the next event without worrying about if the receiver has processed the event yet or not.

A phone call is synchronous. The listener has to understand what you're saying as you say it, or the message doesn't get through. A text message is asynchronous. If you send a second text before the receiver has read your first text, they still get the full message.

In your synchronous Amazon example, if the S3 events happen faster than the lambda function can keep up, events start getting dropped. If there's a queue, you don't have to worry about how fast a burst of events comes in, as long as you have enough long term capacity to process all of them. The sender doesn't have to worry about if the receiver is backed up or not.


For some code to be asynchronous with respect to some other code, it will make arrangements for the other code to run, but then be able to do other things, whilst:

  • having no further interaction with the other code (i.e. not caring about its progress or completion), or
  • periodically checking for the completion of the other code, or
  • later, blocking waiting for completion of the other code, or
  • receiving an event when the other code completes

An event-driven system reacts to events that happen while it's running, such as the arrival of new messages via a network connection. This can be contrasted with a program that only gets inputs from say pre-existing files.

But, given events - synchronous processing might look like this:

while (Event event = get_next_event(network)) {

Async processing lets at least some of the higher-level code continue while lower level processing is happening. It could be that the processing steps are async:

while (Event event = get_next_event(network)) {
    auto async_handles[] = { async_processing_step_one(event),
                             async_processing_step_three(event) };

Above, the steps might run on other threads, and could complete in any order.

It's also possible to have code like this:

while (Event event = get_next_event(network))

...and in say another thread...

while (Event event = work_queue.pop()) {

Then the get_next_event()-calling thread is async with respect to the processing code, as it can be getting further events without waiting for processing of already-received events.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.