When it comes to building software for critical applications, reliability is paramount. One misstep can have devastating consequences, making it essential to choose a technology stack that prioritizes fault tolerance and recovery.

Concurrency types

Race Conditions

Allan updates an ambulance route while Betty simultaneously marks the same ambulance as “engaged” for another emergency. Without proper synchronization, one update could overwrite the other, causing confusion about the ambulance’s destination and availability.

Deadlocks

Allan needs to dispatch an ambulance from Betty’s region for a nearby emergency, while Betty needs a fire truck from Allan’s region for a different incident. If each waits for the other to release the needed resource without communicating, neither region receives the necessary emergency response.

Livelocks

During a severe storm, Allan redirects an ambulance from Betty’s area to a nearby emergency, believing it will be quicker, while Betty, anticipating delays, redirects a fire truck from Allan’s area to another incident. Both continue to redirect resources anticipating each other’s moves without actual progress.

Starvation

Betty manages both emergency and non-emergency dispatches. On a particularly busy day, she is overwhelmed with routine tasks, consuming most of her attention and resources. Meanwhile, Allan urgently needs a specialized rescue team, but the volume of non-essential tasks keeps taking priority, repeatedly delaying his request.

Priority Inversion

Betty is updating equipment maintenance logs, a low-priority task, which inadvertently blocks Allan’s access to the dispatch system, delaying the deployment of a rescue helicopter.

Thread Thrashing

During a local festival, Allan and Betty handle a sudden surge of emergency calls. As they activate numerous processes to manage the calls, dispatch units, and update statuses, the dispatch system becomes overwhelmed, spending time managing which task to handle rather than executing any single task.

Languages and concurrency

Erlang/Elixir (BEAM)

Erlang’s architecture is centered around lightweight processes, each operating in its own memory space with no shared state, enabling true concurrency without the pitfalls of traditional threading models. The BEAM virtual machine efficiently schedules thousands or even millions of these processes simultaneously, optimizing performance and resource utilization. Erlang’s built-in mechanisms for error handling and recovery, such as process linking and supervision trees, enable automatic recovery from failures—a critical feature for systems that cannot afford downtime, such as telecom networks.

Java (JVM)

Java provides a robust threading model alongside a comprehensive suite of concurrency tools. However, this comes with the complexity and overhead of managing shared memory and synchronization. Suitable for building enterprise-level applications, Java’s threading model involves inherent risks like deadlocks, race conditions, and memory visibility issues, requiring developers to manage thread safety explicitly. Additionally, the heavyweight nature of Java threads can pose scalability challenges in systems that demand high levels of concurrency.

JavaScript

JavaScript’s single-threaded event loop is adept at handling I/O-heavy operations typical in web environments, enabling non-blocking operations crucial for real-time web applications. Its concurrency approach, relying on asynchronous callbacks and promises, effectively manages multiple tasks suitable for user interactions and network requests. However, JavaScript does not provide the same level of fault tolerance or recovery capabilities as Erlang’s processes or the robust threading provided by Java, making it less ideal for applications requiring intensive computational tasks or high reliability under load.

Taka away

We often choose our technology stack based on ‘enterprise’ readiness or the availability of a large pool of developers. However, when developing high-stakes systems, where failures can lead to real-world consequences, it becomes crucial to choose a technology that prioritizes fault resolution and recovery capabilities. In this context, Erlang/Elixir stands out as a compelling choice. Its unique architecture enables true concurrency without the pitfalls typically associated with traditional threading models. Moreover, Erlang/Elixir’s built-in mechanisms for error handling and recovery—such as process linking and supervision trees—ensure systems can automatically recover from failures, providing the level of fault tolerance and reliability demanded in these critical environments.