Synchronous vs Asynchronous Event Driven Architecture

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)) {
    processing_step_one(event);
    processing_step_two(event);
    processing_step_three(event);
}

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_two(event),
                             async_processing_step_three(event) };
    wait_for_completion(async_handles);
}

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))
    work_queue.add(event);

...and in say another thread...

while (Event event = work_queue.pop()) {
    processing_step_one(event);
    processing_step_two(event);
    processing_step_three(event);
}

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.