Echonect: Fifteen Years on Apache Camel - Apache Camel A five-part, fifteen-year story of building and running Echonect, one of Europe's larger SMS gateways, on Apache Camel. From a twelve-month rebuild deadline in 2011 to 500+ messages per second per node today, and the boring, durable engineering that kept it running.<br>Posted on July 24, 2026, by Andriy Andrunevchyn Share this blog

❮ ❯<br>By Andriy Andrunevchyn, CTO @Software Service & Innovation<br>A five-part story of building and running one of Europe&rsquo;s larger SMS gateways.<br>In 2011, PayPal gave Echovox twelve months to walk away from the platform its business ran on. This is the story of the platform a small Swiss-Ukrainian team built to replace it, Echonect, and of the boring, durable engineering that has kept it running ever since. It was first published as a five-part series; the five parts are collected here as one.<br>Contents<br>PayPal gave us 12 months to rebuild everything. We bet on Apache Camel.<br>Fifteen years, two countries, one platform<br>In praise of boring technology: fifteen years on Apache Camel<br>Under the hood: three things we got right building an SMS gateway on Apache Camel<br>The whole system on one page, and what Apache Camel gives you<br>Chapter 1. PayPal gave us 12 months to rebuild everything. We bet on Apache Camel.<br>In 2011 I got a call that came with a deadline attached.<br>The short version: PayPal, then owned by eBay, had just acquired Zong, a mobile-payments company, for around $240 million. Zong was a spinoff of Echovox, a Swiss messaging and payments business. When the deal closed, PayPal gave Echovox roughly a year to hand over the software behind it and shut down all of its payment traffic. A year to walk away from the platform the company had been running on.<br>Most teams in that spot would migrate. Copy what exists, move it somewhere safe, keep the lights on. Echovox could not. The ICON SMS gateway that routed the traffic was part of Zong&rsquo;s assets and intellectual property, and none of that code could be reused. Echobill, the billing side, was fine to keep. The routing gateway was not. So Echovox&rsquo;s new management had no choice but to rebuild from scratch, and decided that if they had to build it again, the new one should be more flexible than the thing they were about to lose. Then they went looking for people who could actually do it.<br>That is where my team came in. A small group of Ukrainian developers who had worked together before. Echovox asked the one question that mattered: could we have a new platform ready to start migrating their customers, and above all their connections to mobile operators, inside a year? We said yes. We did not have a detailed plan. We had a whiteboard and a lot of nerve.<br>We also had Serge Haller, Echovox&rsquo;s CTO, who wrote the specifications: a huge stack of documents that pinned down almost every detail of how the new platform should behave. The nerve was ours. The map was his. How that partnership worked, and why it is still working fifteen years later, is Chapter 2 of this story.<br>Why Camel, of all things<br>The first real decision was the backbone. We were building a system that had to take messages in from a hundred-plus external connections, each with its own format and quirks, run business rules over them, and push messages back out to other networks. High volume, many moving parts, and a clock ticking.<br>We chose Apache Camel. At the time it was not the obvious pick. The two safe options were both bad. Hand-roll our own message router, and spend a year writing plumbing we did not have a year for. Or bolt everything onto a heavyweight enterprise service bus, the kind that was fashionable then, and inherit weight we did not want. Camel sat in between. It is an integration framework built on well-worn patterns for moving messages between systems, and it gave us two things we needed. Development speed, because most of the plumbing we would otherwise have written by hand already existed and was tested. And modularity, because Camel let us treat each route as a self-contained piece we could reason about on its own.<br>The second point turned out to matter more than the first. When you are connecting to a new mobile operator every few weeks, the ability to add a piece without disturbing the rest of the machine is close to the whole game.<br>What we actually built<br>The platform we shipped, and still run, is a single solution built from four modules, each deployed on its own: one receives everything coming in from providers, one applies the compliance, tariff, and routing rules, one dispatches outbound messages to the external networks, and one handles reporting. They talk to each other over ActiveMQ, asynchronously, so a slow provider on one end cannot freeze the whole pipeline. Chapter 5 walks through the machine properly; this is just the silhouette.<br>Inside, a message moves through three shapes. It arrives as an inbound SMS. It becomes an outbound SMS once the rules have run. It produces a delivery...