When Facebook paid $19 billion for WhatsApp in 2014, the entire engineering team fit in a large conference room. Fifty engineers were running a messaging service for 450 million people, moving something close to 50 billion messages a day, off commodity servers that were nowhere near as exotic as the traffic numbers suggested. The reason a team that small could carry that much weight was not luck or a hiring miracle. It was a language called Erlang, built by Ericsson to run telephone switches that were not allowed to go down.
That story still gets told in conference talks and interview prep guides, but it raises an obvious question for anyone building a messaging product, a real time notification system, or anything that needs to hold millions of open connections at once: is Erlang still a serious option, or is it a museum piece that one famous acquisition happened to make famous? Looking at where the language and its ecosystem stand today, the honest answer is that Erlang in 2027 is doing quiet, unglamorous, extremely reliable work at companies most developers have never heard mention it.
This piece walks through what actually makes Erlang suited to WhatsApp scale messaging, how the language has moved since that 2014 deal, and what current Erlang development trends 2027 look like for anyone deciding whether to build on it today.
A Short Timeline: From Telephone Switches to Chat Apps
Erlang's path to WhatsApp did not happen overnight, and seeing the milestones in order helps explain why the language was mature and battle tested by the time a small chat startup needed it:
What Erlang Actually Is
Erlang was not built for chat apps or social networks. Ericsson created it in 1986 for telephone exchange software, a domain with a strict requirement: calls cannot silently drop, switches cannot crash for hours, and one bad line of code cannot bring down a phone network serving an entire region. That requirement shaped everything about the language.
Erlang is a functional language, meaning data does not change in place once created. It ships with a runtime called the BEAM, short for Bogdan and Bjorn's Erlang Abstract Machine, and a standard library called OTP, short for Open Telecom Platform, that bundles the patterns telecom engineers used over and over: supervision, distribution, hot upgrades, and a process model that has nothing to do with operating system threads.
Ericsson open sourced Erlang in 1998 after nearly ten years of internal use, mostly inside switches handling millions of calls without anyone outside the company noticing. That quiet, boring reliability record is exactly what drew WhatsApp's founders in a decade later.
Why WhatsApp Bet on Erlang
WhatsApp was founded in 2009 by Jan Koum and Brian Acton, both former Yahoo engineers. From day one, the product had one job: deliver short messages to phones over unreliable mobile networks, fast, and never lose them. That is a concurrency problem before it is anything else. Every user who opens the app holds a connection open to a server, sometimes for hours, and the server has to track presence, buffer undelivered messages, and hand off traffic the moment a phone reconnects after switching from WiFi to a mobile network.
Koum chose Erlang early, and he was blunt about the reason in later interviews: it was the right tool for a problem that was fundamentally about holding millions of connections open at once with predictable behavior. At the time, the alternative was writing a custom event loop in C or Java using operating system threads, and accepting that each thread would cost a megabyte or more of memory before it did any real work. Erlang processes, by contrast, start at a few hundred bytes and grow only as needed.
The choice paid off in a way that is easy to state and hard to reproduce. By 2014, a single WhatsApp server was holding roughly 2 million concurrent connections. The company ran with about 50 engineers across iOS, Android, servers, and operations while serving 450 million monthly users, a ratio that later estimates put somewhere between 9 million and 40 million users per engineer as the user base kept climbing toward 2 billion. No team that size stays that small by writing more code. It stays small by writing less code that does more, and that is what the platform allowed.
The Process Model: One Connection, One Lightweight Process
The single biggest reason Erlang fits messaging systems is its approach to concurrency. In most languages, handling 100,000 simultaneous connections means managing operating system threads, a thread pool, or an event loop with callbacks scattered across the codebase. Erlang sidesteps all three. Every unit of work, including every single user connection, runs as its own lightweight process inside the BEAM. These are not operating system threads. They are managed entirely by the Erlang runtime, they do not share memory with each other, and they communicate only by sending messages.
That isolation is what makes the scale numbers possible. A WhatsApp connection could be represented as one process holding a small amount of state: who the user is, what they are subscribed to, what messages are queued. When a message arrives for that user, another process simply sends it a message. There is no shared data structure to lock, no risk that two threads corrupt the same memory at once, and no thread pool to size correctly under load.
Here is roughly how the numbers compare to the alternative most backend teams reach for by default:
The practical result of this design is what WhatsApp actually reported: about 2 million connections on a single server, on commodity hardware, well before most companies were thinking about that kind of density. The same pattern shows up elsewhere. Discord, which also runs on the BEAM through Elixir, has spoken publicly about handling millions of concurrent users through a similar process per connection model.
The BEAM Scheduler: How Millions of Processes Share a Few CPU Cores
Having millions of lightweight processes only helps if the runtime can actually run them fairly on a machine with, say, 32 or 64 CPU cores. This is where the BEAM scheduler does its work, and it is worth understanding because it explains why Erlang systems tend to stay responsive even under heavy load rather than degrading gradually the way many other runtimes do.
The BEAM runs one scheduler thread per CPU core by default, and each scheduler manages its own run queue of processes waiting for CPU time. Instead of letting one process run until it chooses to yield, the way cooperative systems do, the BEAM counts reductions, roughly one reduction per function call or similar unit of work, and preempts a process automatically once it has used its share. A process cannot hog a core by accident, and a runaway loop in one connection handler cannot starve the other 2 million connections on the same box of CPU time.
This preemptive, reduction counted scheduling is a big part of why WhatsApp could push a single server to 2 million connections and still keep latency predictable. The scheduler also moves processes between cores to balance load, and it handles garbage collection per process rather than pausing the entire runtime the way a global garbage collector does in many other languages. A large heap in one process does not freeze every other process on the machine while it gets cleaned up.
Let It Crash: Supervisor Trees and Fault Tolerance
Erlang's other defining idea is almost the opposite of how most languages teach error handling. Instead of wrapping every risky operation in a try and catch block and trying to anticipate every failure mode, Erlang encourages a philosophy summed up as let it crash. A process that hits an error it was not built to handle is simply allowed to die.
That sounds reckless until you see the second half of the design: supervisor trees. Every process in a well built Erlang system sits under a supervisor, a separate process whose only job is watching its children and deciding what to do when one dies. A supervisor can restart the failed process, restart a whole group of related processes, or escalate the failure upward if it cannot recover on its own. None of this requires the developer to predict every possible failure in advance. It requires only that failures stay contained to the smallest possible part of the system.
For a messaging platform, this maps directly onto real operational problems. If the process handling one user's connection hits a bug, maybe a malformed message, maybe a network hiccup it was not expecting, only that one process dies and restarts in a clean state. The other 2 million connections on that same server never notice. Compare that to a single threaded or shared memory system, where an unhandled exception in one request handler can take down the whole process, along with every other connection it was serving.
This is also the mechanism behind a question a lot of engineering teams ask directly: how Erlang is used for fault-tolerant concurrent systems in 2027 comes down almost entirely to this pattern, applied consistently at every layer of a system rather than kept as an occasional safety net.
Hot Code Swapping and Zero Downtime Updates
One more Erlang feature mattered enormously for a 50 person engineering team: hot code swapping. Erlang was built so a running system can load new code and switch over to it without dropping active processes or restarting the machine. For telecom switches, this made sense immediately. You cannot ask a phone company to hang up every active call in a region just to deploy a patch.
For WhatsApp, the same feature meant engineers could ship fixes and improvements without disconnecting users mid conversation, something that mattered a great deal at a company shipping to hundreds of millions of phones on inconsistent mobile networks. It also meant the operations burden of deployment did not scale linearly with the number of servers the way it does in systems that require rolling restarts or connection draining before every release.
Distribution, Storage, and Message Delivery
Concurrency inside one machine only solves part of the problem. WhatsApp also had to move messages between servers, across data centers, and eventually across a global user base. Erlang was built with distribution as a first class idea rather than a bolted on library. Nodes running the BEAM can form a cluster and send messages to processes on other machines using the same syntax used to talk to a process on the same machine, which keeps the mental model consistent even as the system grows.
WhatsApp paired this with Mnesia, Erlang's own distributed, in memory database, for the parts of the system that needed fast, replicated access to state such as presence and session data. Messages themselves were typically held only until delivery, then removed from the server rather than kept in a long term store, which kept the storage layer lean and matched the actual product requirement: get the message to the device, not archive it forever on a server WhatsApp had to pay for.
None of this was exotic engineering. It was closer to the opposite: a small set of well understood, battle tested pieces, Erlang processes, supervisor trees, Mnesia, a modified XMPP protocol served through ejabberd, combined carefully and tuned relentlessly at the operating system level, right down to FreeBSD kernel parameters for file descriptors and socket handling.
WhatsApp by the Numbers
It helps to see the growth in one place rather than scattered across separate claims:
The team size grew after Facebook's acquisition, as any company serving billions of people eventually needs more hands for compliance, abuse prevention, payments, and regional features that have nothing to do with core message delivery. What did not change is the underlying architecture pattern: lightweight processes, supervision, and a small number of large, carefully tuned machines rather than a sprawling fleet managed by a large infrastructure team.
Erlang in 2027: Where the Language Stands Now
Erlang in 2027 is not the same project it was when WhatsApp adopted it in 2009, even though the core ideas have not moved. The language is maintained by the OTP team at Ericsson alongside an active open source community, and recent releases show a project being kept current rather than preserved as a museum piece.
Erlang and OTP 28, the major release carried through 2026, added priority message handling for processes, better compiler error messages that suggest likely fixes, and a formal software bill of materials for each release, a detail that matters more now that supply chain security is a standard procurement requirement for any language a serious company builds on. Patch releases through the year focused heavily on security fixes, including hardening around buffer handling in areas like SCTP chunk parsing, work that reflects Erlang's roots in telecom infrastructure where that kind of attack surface has always mattered.
An earlier release, OTP 24, added a just in time compiler known as BeamAsm, which gave the runtime a real performance jump on modern multi core hardware without asking developers to change how they write code. That single change mattered more for the ongoing health of Erlang in 2027 than almost anything else on this list, because it answered the most common objection long term Erlang users heard from newer teams: that the runtime was fast enough for concurrency but slow for raw computation.
Erlang Development Trends 2027
The clearest way to describe Erlang development trends 2027 is that the language itself has become a stable foundation while most of the new energy sits one layer up, in Elixir. Elixir, created by Jose Valim in 2011, runs on the same BEAM, keeps the same process model and supervisor trees, and adds a syntax closer to Ruby, along with the Phoenix web framework and its real time LiveView tooling. A large share of companies adopting BEAM technology today choose Elixir on top of Erlang rather than writing Erlang directly, and job market data reflects that shift.
Public salary and hiring data through 2026 puts senior Elixir engineers in the United States in a range from roughly $107,000 at early stage startups up to $250,000 at companies like Discord or Remote.com hiring specifically to architect distributed systems on the BEAM. Contract rates run between $80 and $120 an hour. The pool of engineers with deep OTP experience, meaning supervision trees, distributed clustering, and hot upgrades rather than just Phoenix web development, stays small relative to demand, which keeps compensation high for people who actually understand the runtime rather than just the syntax on top of it.
Job board data from outside the United States tells a similar story: a small, steady market rather than a shrinking one. UK postings citing Erlang or Elixir skills climbed year over year through the period leading into 2026, and reported median salaries for permanent roles requiring these skills sit well above the general market average, reflecting both scarcity and the seniority of the roles on offer.
Numbers like these point to a market that rewards depth over breadth. There are not many roles, but the roles that exist tend to pay well and go to engineers who have actually operated a BEAM system in production, not just read about the actor model. A short list of the kind of company still choosing this stack deliberately, and shaping Erlang development trends 2027 in the process:
• Discord, for real time chat and voice infrastructure serving tens of millions of concurrent users
• Klarna, for payment systems where a crash cannot be allowed to corrupt a transaction
• The BBC, for services that need to absorb sudden traffic spikes around major news events
• Remote.com, for a distributed HR and payroll platform that must stay correct across time zones and currencies
• RabbitMQ, one of the most widely used message brokers in the industry, itself written in Erlang
None of these are companies that backed into the BEAM by accident. Each one evaluated alternatives and made a documented, deliberate choice, usually after running into the limits of thread based concurrency models somewhere else first.
How Erlang Is Used for Fault-Tolerant Concurrent Systems in 2027, Beyond Messaging
Messaging apps are the most famous example, but they are not the only place this pattern applies. Understanding how Erlang is used for fault-tolerant concurrent systems in 2027 means looking past WhatsApp to the industries that quietly depend on the same properties: telecom networks, financial systems, multiplayer games, and connected device fleets.
Telecom carriers still run Erlang in the switches and session border controllers it was originally built for. Ericsson's own network equipment, the reason the language exists at all, continues to rely on the same supervisor pattern to keep call routing available during hardware failures and software upgrades.
In fintech, the appeal is different but related. A payment system cannot silently lose a transaction or double charge a customer because one process crashed mid operation. Klarna has spoken publicly about choosing Erlang for exactly this reason, favoring a system that fails safely and recovers automatically over one that requires perfect exception handling in every code path.
Multiplayer gaming backends face the same connection density problem WhatsApp solved. Riot Games has reported handling millions of concurrent League of Legends chat connections using BEAM based infrastructure, and the reasoning matches WhatsApp's almost exactly: many long lived, lightweight connections that each need isolated state and fast message passing.
Connected device platforms are a newer but growing case. A fleet of sensors reporting telemetry behaves a lot like a fleet of chat clients: many independent, intermittent connections, each one small, each one needing to reconnect gracefully after a network drop. The process per connection model that suited phone based chat in 2009 suits sensor based telemetry just as well today.
Should You Build on Erlang Today?
None of this means Erlang is the right default choice for a new project. It solves a specific problem extremely well: high concurrency with strict reliability requirements. Outside that problem, the tradeoffs are real.
Choosing Erlang in 2027 means accepting a smaller hiring pool and a language most teams are not already fluent in, in exchange for a runtime that has spent close to four decades proving it can stay up. For the right problem, mostly systems that look like WhatsApp did in 2009, that trade is usually worth making. For a typical web application with modest concurrency needs, it probably is not, and a mainstream language with a deeper hiring pool will get a team to market faster.
One factor that softens the hiring risk is that Erlang does not have to run the whole company. Many teams keep the connection handling and coordination layer, the part that benefits most from the process model, on the BEAM, while writing CPU heavy pieces such as image processing, machine learning inference, or video transcoding in a separate service and calling it over a network boundary or through a native implemented function. This lets a team get the fault tolerance benefits where they matter most without needing every engineer on staff to know Erlang.
Key Takeaways
Pro Tips
Conclusion
WhatsApp did not succeed because of a clever growth hack or an unusually gifted team of 50 people, though the team clearly was talented. It succeeded because the technology underneath matched the actual shape of the problem: millions of small, independent, long lived connections that needed to stay up and recover from failure on their own. Erlang in 2027 is still built for exactly that problem, and the companies still choosing it, from Discord to Klarna to Ericsson's own networks, are making the same bet WhatsApp made in 2009 for the same reasons. It will never be the most popular language on a job board. For the specific job of keeping millions of people connected at once without falling over, it remains one of the most proven.
