In this architectural style, the fundamental elements in the system are events. Events can be signals, user inputs, messages, or a data from other functions or programs. Events act as both indicators of change in the system and as triggers to functions. In this paradigm, functions take the form of event generators and event consumers. Event generators send events and event consumers receive and process these events. A function can be both an event generator and an event consumer. Event consumers are called implicitly based on event sent from event generators.

Event-based functions experience implicit invocation. The defining feature of implicit invocation is that functions are not in direct communication with each other. All communication between them is mediated by an event bus. We can think of the event bus as the connector between of all event generators and consumers in the system.

To achieve this structure, we first bind an event and an event consumer via the event bus. That is, each event consumer registers with the event bus to be notified of certain events. When the event bus detects an event, it distributes the event to all appropriate event consumers. When the event bus detects an event, it distributes the event to all appropriate event consumers. The observer design pattern manifests the event-based architectural style.

One way to implement the event bus is to structure the system to have a main loop that continually listens for events. When an event is detected, the loop calls all the functions bound to that event.

Pipe and filter architecture, which is a type of data flow architecture. Data flow architecture considers a system as simply a series of transformation on sets of data. Data is transformed from one form to another using different types of operations. A pipe and filter architecture has independent entities called filters which perform transformations on data input they receive, and pipes, which serve as connectors for the stream of data being transformed. 

The changes to the data are done sequentially from filter to filter. Each filter performs its local transformation on the data input it receives from the previous pipe and then it sends the output onto the next pipe.

• State. The information that a system remembers defines its state. For example, a queue system can be in a number of different “states”: an empty state, a queued state, or a full state.
• Transition. A transition is used to describe the change of a system from one state to another. A single system state can have multiple transitions; majority of systems today will have multiple transitions branching from one system state. This makes behaviors non-deterministic, since we cannot predict what the next state of the system will be.
• Behavior. The behavior of a system describes what the system will do when exposed to a condition, which can vary from timed system events to user input.

State transition systems can be thought of as directed graphs. Each node of the graph represents the set of states, and each edge of the graph represents the set of transition. We can determine how a system reaches a specific state by simply traversing the graph.

State transition systems can help us understand how parallel processing, multithreading, or distributed computing can affect the overall state of our system. Do we need to wait for another process to finish its work before continuing? At which junction of our system will we be bottlenecked?

In addition, state transition systems can help us identify deadlocks. A deadlock occurs when a process is waiting indefinitely for another to release a shared resource or complete its work. A state transition system can help you easily identify deadlocks since they occur if there is a condition that prevents a transition out of particular state.

Another name of the n-Tier is Multitier. Tiers often refer to components that are on different physical machines. The number of tiers varies quite a bit, 3- and 4-tier architectures are quite common, but any number is possible. So this architecture is called n-Tier or a Multitier.

The relationship between 2-Tiers in an n-Tier architecture is often a client/server relationship. The server side provides services. This could be storing information in a database, performing computation tasks, any sort of service. The client-side requests these services through messages. The communication between the two sides is called Request-Response. A tier can act as both a server and a client, simultaneously fulfilling the requests of its clients and making requests of its servers.

2-Tier Architecture (Client Tier and Data Tier):