Thread Architecture vs Staged Event-Drive Architecture in real life:

Imagine you have a restaurant. Now, how it will work?

with "Thread Architecture":

1. A customer arrives
2. Waiter(a) goes to him/her
3. Waiter(a) takes him/her to one available table
4. Waiter(a) takes the order
5. Waiter(a) cooks the order
6. Waiter(a) takes to order to the table
7. Waiter(a) waits until the client finishes his/her meal to pay
8. Waiter(a) walks the client out

In this case, the waiter is with the client during the whole process. If the server has 10 threads, can handle 10 connections concurrently.

with SEDA:

1. A customer arrives
2. Waiter(a) goes to him/her
3. Waiter(a) takes him/her to one available table (and comes back for another client to come)
4. Waiter(b) takes the order (lots of I/O, takes time)
5. Cook cooks the order
6. Waiter(c) takes to order to the table
7. Waiter(d) waits until the client finishes his/her meal to pay
8. Waiter(e) walks the client out

In this case, there are different kind of actors doing the activities. This helps to reuse actors in the activities that take less time and the outcome is more effective. Indeed, this is how a restaurant works (probably more instances of Waiter are the same person, but the cook definitely not).

This is an extreme example, and of course with threaded servers some async tasks can be done. This is only a theoretical example.

A Stage is analogous to an "Event". To simplify the idea, think of SEDA as a series of events sending messages between them.

One reason to use this kind of architecture, I think, is that you fragment the logic and can connect it and decouple each event, mainly for high performance services with low latency requirements fits well.

If you use Java TPE, you could monitor the health, throughput, errors, latency of each stage, and quickly find where the performance bottleneck is. And as a nice side effect, with smaller pieces of code, you can easily test them and increment your code coverage (that was my case).

For the record, this is the internal architecture of Cassandra (NoSQL), and Mule ESB (AFAIK).

I recommend reading the original paper (sorry, duplicate link):

• https://github.com/mdwelsh/mdwelsh.github.io/blob/master/papers/seda-sosp01.pdf

Here is a framework I ve created to model SEDA for Java EE: http://code.google.com/p/seide/

The docs are available at github

SEDA as mentioned in the document: "The fundamental unit of processing within SEDA is the stage. A stage is a self-contained application component consisting of an event handler, an incoming event queue, and a thread pool... Each stage is managed by a controller that affects scheduling and thread allocation. Stage threads operate by pulling a batch of events off of the incoming event queue and invoking the application-supplied event handler. The event handler processes each batch of events, and dispatches zero or more events by enqueuing them on the event queues of other stages."

To me, you could design your stage as a logical modularization of your application flow. It could be based on functionality, based on separation of concerns, based on performance, based on operations and maintenance.

I would ask you to read the attached PDF as it mentions the need for a event queue to decouple stuff, logical compenentization to achieve maximum efficiency of the component, how to efficiently reuse the existing resources above which the application is running like network, storage, CPU cycles etc.,

To draw a parallel, there are studies made on assembly line workers who worked in series assembling something from start to end achieved less productivity, but when they were isolated and made to do a single job and pass the partly assembled unit to the next group, each one of them became efficient in managing his/her work. Basically your flow of assembling something got split into multiple stages and each one of them or a group of them were responsible to work on a stage.

All that was done here was to enable and set-up a framework around each person or group and a mode of communication from one person/group to another. Now we can compare each person/group and the framework set-up around him to a stage.

To add the event dimension in SEDA, think about how the person group communicate with each other and the number of events which are involved. Say for example, the stage 1 guys have ran out of nuts and bolts to complete their stage and they immediately inform the Order Section manager about the nuts and bolts. It is possible that the order section manager has got a similar request from another stage 6 guys that nuts and bolts have run out. Now, he sees the requests at a central point (he is like the controller in SEDA) and the excel sheet which he has where all the entries he has kept the requests of orders to be placed (is like the queue in SEDA), he combines them and orders them together at one go instead of sending two order requests (thread and schedule management in SEDA).

Now if you have a mechanism like that in your software architecture which has multiple components, sending various events to each other and have controllers consuming them and acting accordingly, then you probably have a very good staged event driven set-up in place.