## 3 An Event-Based IoT Architecture
It is distributed at its core, fault-tolerant, focused on scale, throughput, and retention, and fundamentally consists of (i) message queuing, (ii) message processing, and, last but not least, (iii) message storage. All architecture components are built on a backbone of events, where events become both a trigger and a pattern for distributing states. **Event Engine and Process Engine**[42]: The purpose of the components is to provide functionality for providing information and performing actions. In any case, raw data are converted into events, and events into meaningful events, on the backbone of which we create services. Event Engine transforms data from IoT Physical to IoT Events. IoT Events can be used by Process Engine to create Application Events with the final destination, the Applications and Clients layer. Process Engine transforms data from the Applications and Clients layer to Application Events. Event Engine can use Application Events to create IoT Events with the final destination, the IoT Physical layer. Both engines are distributed and implement Complex Event Processing to achieve their intended use. **IoT Gateway**[42]: Connects the Center of the System layer with the IoT Physical layer, i.e., establishes direct communication with IoT Physical. The communication is standardized, based on a widely used and established protocol, and can be synchronous or asynchronous. It consists mainly of transports, which are services that establish two  
Figure 1: Architecture overview. way communication with the IoT devices of IoT Physical, i.e., the physical environment. Transports may include MQTT, CoAP, LwM2M, and, last but not least, HTTP. **Application Gateway**[42]: It acts as a single entry point for all applications and clients and provides an effective way to route to APIs through the Center of the System layer. Multiple Application Gateways may cater to the needs of different kinds of clients. For example, an Application Gateway can be a basic reserve proxy or even a complete API Management System that may provide cross-cutting concerns to APIs, such as security, monitoring, resiliency, smart and/or conditional routing. The architectural components are dynamic and heterogeneous. The number of their instances and physical or virtual locations changes dynamically, as well as their intercommunication protocols. Hence, the role of an Application Gateway is vital,as it provides clients with a unified, consistent, and standardized way of accessing the Center of the System layer through the provided APIs. By its nature, the proposed event-driven architecture is extremely loosely coupled and highly distributed. Although it is intended that the architecture be technology-agnostic, we propose utilizing Apache Kafka [44], an open source distributed event streaming protocol used for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. It follows the concept of dump broker/smart consumer, which puts all the focus on doing one thing in a highly effective manner, i.e., scalable and fault-tolerant data distribution. This concept shifts the implementation responsibility and the emerging logical complexity to the consumer side, which is very convenient for our approach, since we have all the offerings by the event broker focusing on data distribution and simultaneously have total control of the application focusing on the processing of data. Overall, the proposed symmetrical architecture contributes significantly to the aim of this research, which is to describe and implement the transformation cycle of raw data to meaningful events that serve the requirements of the application domain. More specifically, data from IoT devices are progressively transformed into IoT Events and, finally, business events. Respective data from Applications and Clients are progressively transformed into Application Events and finally business events. Both types of events can trigger further transformations.