From small to large: tackling performance challenges in scaling Emergency Alert Systems (EAS) 

From small-scale implementations to large deployments, we address performance challenges in scaling Emergency Alert Systems (EAS). The global market for Emergency Alert Systems (EAS) is projected to grow annually by 12.1% (CAGR 2024 – 2031). The reliability of EAS systems is crucial regardless of scale. Are they ready to handle thousands of devices simultaneously? Discover the causes of performance issues that may arise and how to effectively address them to ensure rapid and reliable alerts in any situation. 

Key performance issues of EAS 

The growth of the Emergency Alert System (EAS) market brings significant challenges and opportunities for system providers. Scaling systems is becoming increasingly important as the demand for new devices and large-scale installations grows. As the EAS market expands, providers must meet the increasing demands in terms of the number of supported devices and system performance. 

Key issues faced by these service providers include: 

Outdated architecture 

Systems designed several years ago were prepared for a significantly smaller number of devices than currently required. Older technologies and protocols are less efficient at managing a large number of simultaneous connections. 

• Increased number of requests: More devices mean more server requests, which can overload the system. 
• Performance degradation: Systems designed for fewer units start to slow down as the number of devices grows rapidly. 
• System crashes: In extreme cases, the system can completely crash. 

Inefficient communication  

Each device sends a separate request to the server, causing a massive increase in the number of requests with a large number of devices. The number of requests grows proportionally to the number of devices, which can lead to server overload and significant delays in processing requests. 

• Individual HTTP requests: In a traditional REST API-based architecture, each device sends an individual HTTP request to the central server. 
• Server overload: With a large number of devices, the number of requests rises sharply, leading to server overload. 
• Delays: Sequential processing of requests causes significant delays. Each request must be processed, and a response must be sent back, which can take a very long time with thousands of devices. 

Lack of cloud services utilization 

Some systems cannot use cloud services due to strict data security requirements. Sensitive data must be stored and processed locally, eliminating the possibility of using flexible and scalable cloud services. 

• Infrastructure limitations: Some systems cannot use cloud services due to data security requirements or physical infrastructure. 
• Lack of scalability: The inability to use scalable cloud resources limits the system’s ability to handle an increasing number of devices. 
• Increased costs: Deploying and maintaining own physical infrastructure is costly and less flexible compared to cloud solutions. 

Solutions to EAS performance issues 

To effectively manage the growth in the number of devices in EAS, it is crucial to implement modern architectural and communication solutions, such as the MQTT protocol and MQTT brokers, and the implementation of edge computing and load balancing. These changes will allow for efficient system scaling, reduction of server load, and ensuring fast and reliable communication in emergency situations. 

Use of MQTT Protocol 

• Communication efficiency: MQTT is more efficient than REST API due to its asynchronous nature and publish/subscribe model. It reduces the number of necessary connections and data transmitted, easing the server load. 
• Scalability: With MQTT, the system can handle a much larger number of devices without a drastic drop in performance. 

Implementation of MQTT Brokers 

• Server load reduction: The publish/subscribe model prevents continuous individual request processing by the server. 
• Asynchronous communication: Asynchronous communication allows for more efficient management of a large number of devices. 

Load Balancing 

• Traffic distribution: Implementing load balancing allows for the distribution of network traffic across multiple servers, reducing the risk of overloading a single server. 
• Flexibility and reliability: Load balancers can dynamically allocate resources based on current load, providing better system flexibility and reliability. 

Edge Computing 

• Local data processing: Processing data closer to the source (on end devices) reduces the load on the central server, improving the overall Emergency Alert System performance. 
• Faster responses: Edge computing enables faster responses to local data, which is crucial in emergency situations. 

Case Study

Explore how the use of the MQTT protocol and MQTT broker enhances communication and addresses performance challenges in scaling Emergency Alert Systems (EAS). A web-based alarm and warning management system for civil defence encountered the scalability issues described above. The system is used to monitor and manage alarm points in real-time, protecting the population from threats such as floods, disasters, chemical contamination, and war. It allows the processing and analysis of data from various sensors (chemical, gamma radiation, water level, weather stations) and includes solutions for remote control of sirens. 

Architecture of Emergency Alert Systems 

The described Emergency Alert System (EAS) consists of a network of devices acting as alarm points. A central device communicates with subordinates via REST communication in HTTP API. Initially, the system architecture was designed to handle a small number of units – from a few to several dozen. 

Challenges in EAS communication 

Communication within the system is carried out without the need for internet access as an independent local network with additional use of radio. The system is independent of external providers like AWS, Google, or Microsoft to avoid dependency on the failure of such services. Servers are located at the Ministry of the Interior and Administration and selected Voivodeship Offices, ensuring system operation as long as these locations have power and internet. 

In communication between alarm points and the central unit, radio is used because it is impossible to create an internal network connecting several cities. 

Performance issues in EAS

As the system grew to several thousand devices managed by a single central device, significant performance problems emerged. Controlling many devices from the central unit encountered issues. The server continuously sent requests, resulting in constant overload. Consequently, the system began to slow down. The difference in triggering alarms on all devices increased from a few seconds to even several minutes. In extreme cases, the system crashed and stopped responding. 

Cause of EAS performance issues

The Emergency Alert System (EAS) encounters significant performance issues primarily due to improperly chosen communication architecture. The main source of problems is server overload caused by the burdensome REST communication type. REST communication is effective with a small number of devices. However, as the number of devices increases to thousands, the number of requests sent to the server grows exponentially. Each device regularly informs the server about its status, such as voltage or door opening. This generates thousands of requests that the server must process, further burdening the system. As the number of devices grows, the system cannot process all requests in a timely manner, leading to significant delays and performance degradation. The system must process each request individually, which, with a large number of requests, significantly burdens the server and extends response times.

Solution to EAS performance issues 

After identifying the problems related to server overload and inefficient REST communication, several key changes were implemented in the Emergency Alert System (EAS), significantly improving its performance. The main solutions included the use of the MQTT communication protocol and MQTT brokers:

MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol designed to transmit messages between devices efficiently and reliably. It specifies how devices can transmit messages to each other efficiently and reliably.

An MQTT broker is software or a server that manages communication between MQTT clients. It is the central component of the MQTT infrastructure. It manages communication, routing messages between clients according to the rules defined by the MQTT protocol.

Benefits of implementing selected solutions

Advantages of implementing the MQTT protocol:

• Publish/subscribe model: MQTT operates on a publish/subscribe basis, allowing devices to publish messages on specific topics and subscribe to these topics to receive messages.
• Lightweight: The protocol is designed to operate in resource-constrained environments, such as IoT devices, where memory and computing power availability is limited.
• Small headers: MQTT message headers are very small, reducing the amount of data transmitted and increasing communication efficiency.

Advantages of implementing the MQTT protocol:

• Independent communication: An MQTT broker operates as an independent server managing communication between devices. It receives messages from publishing devices and delivers them to appropriate subscribers. 
• Serverload reduction: The broker offloads the main server from continuous request processing. It can store messages for unavailable devices and manage persistent sessions, reducing the main server’s load. 
• Asynchronous communication: An MQTT broker enables asynchronous communication, allowing efficient management of many devices without generating significant delays. 

Additionally, using an MQTT broker leads to resource and energy savings: 

• Lower memory and RAM usage: MQTT uses less RAM thanks to smaller headers and more efficient communication. 
• Data transfer savings: The lightweight nature of MQTT reduces the amount of data transmitted, lowering transfer costs and reducing network load. 
• Low energy consumption: Devices communicating via MQTT consume less energy, which is crucial for battery-operated or limited-power devices. 

Summary 

Switching to the MQTT protocol and implementing MQTT brokers significantly improved the EAS system’s performance. Reducing the number of requests to the server, efficient communication management, and resource savings eliminated overload and delay issues. With these changes, the EAS system is now more scalable, reliable, and ready to handle thousands of devices simultaneously.