See how Conduit balances speed, reliability, and scale making customer conversations faster than ever.
Introduction : Building Conduit
Every startup has that one project where the team collectively goes, “Yeah, this is it. This is the good stuff.” For us at RhythmiqCX, that project is Conduit, the messaging backend that keeps every support conversation flowing like water. Because let’s face it: AI customer support without fast, reliable, real-time messaging is like a Ferrari running on bicycle tires. Shiny on the outside, chaos on the inside.
So in this post, I’m going to take you behind the curtain. Not with stiff whitepaper language, but the way I’d explain it to a fellow founder over coffee stories, idioms, and all. Buckle up, because Conduit is part engineering masterpiece, part survival story, and part “wow, I can’t believe that worked.”
Why Reinvent the Wheel?
“Wait,” you might be thinking, “aren’t there a hundred messaging systems already?” True. Slack, WhatsApp, Teams, Discord you name it. But customer support is its own beast. You’re not just sending memes or cat pictures. You’re juggling:
- High stakes a billing error, a healthcare query, a banking request. Mess that up and trust tanks fast.
- AI copilots bots that step in, hand off, and sometimes disappear mid-conversation like that one flaky friend.
- Compliance logs, permissions, filters, billing hooks… boring but absolutely critical.
- Scale thousands of concurrent chats, because nobody likes waiting in line for support.
That’s why we didn’t just want a messenger. We needed an engine. Something fast, reliable, and flexible enough to let our AI shine. And like any good startup, when we couldn’t find exactly what we needed, we rolled up our sleeves and built it ourselves.
The Client-Server Model: Boring, but Brilliant
Tech circles love hyping up peer-to-peer (P2P). Decentralization! No single point of failure! Privacy! Sounds amazing… until you realize you’re building SaaS, not a pirate radio network.
In the real world, businesses need centralized authentication, usage tracking, billing, content filters, and (increasingly) AI agents. That’s why Conduit sticks to the Client-Server model.
When Alice sends a message to Bob, it doesn’t teleport. It first goes to the App Server, which does the unglamorous but necessary chores: authenticates Alice, checks her permissions, applies filters, logs the event to the database, triggers billing, and then delivers it to Bob.
It’s not sexy, but it works. And sometimes, boring is exactly what you want. Think of it like traffic lights: nobody writes think-pieces about them, but try driving without them and you’ll miss them real quick.
The Lego Bricks of Conduit
We like to think of Conduit as a Lego spaceship. Every block is simple on its own, but snap them together and you’ve got a sleek, interstellar ride. Here’s the kit:

Each component is implemented using FOSS tools.
- Centrifugo Our pub/sub server, written in Go. Handles WebSockets, SSE, gRPC. It’s the FedEx of Conduit: delivering packets instantly, globally, and reliably. Plus, it scales horizontally using Redis like it was born for it.
- FastAPI Python’s async superstar. Simple enough to hack fast, powerful enough to handle production loads. It runs our HTTP API for sending and receiving messages. (Also, devs actually enjoy using it. That’s rare.)
- PostgreSQL The “world’s most advanced open-source database,” and yeah, we’re fanboys. Transactions, JSONB, reliability… honestly, Postgres feels like that friend who’s good at everything and somehow still humble.
- Redis Currently the glue holding our Centrifugo cluster together. Fast as lightning, simple as duct tape, and just as essential when things scale.
All open-source. All proven. And all playing nice together in Conduit’s architecture.
The Hard Part: Making Distributed Systems Behave
Anyone who’s built a distributed system knows the pain: doing two things at once without losing your sanity. Specifically, updating database state AND notifying another service atomically. Miss one, and you’re in bug city.
We had nightmares of messages being saved but never delivered, or worse delivered but never logged. Imagine explaining that to a compliance auditor. Yeah, no thanks.
Our solution? The Transactional Outbox Pattern. Whenever a message comes in, we store it in Postgres and create an outbox event in the same transaction. Then our Event Dispatcher (built on the Polling Publisher Pattern) scoops up new events and fires them off to Centrifugo. From there, Centrifugo delivers them in real-time.
The result: atomic, reliable, and wicked fast. Like a relay race where nobody drops the baton because dropping the baton in messaging means someone’s refund request vanishes into the void.
A Day in the Life of Alice and Bob
Let’s replay a simple conversation. Alice sends Bob a message: “What’s up?” Here’s what actually happens behind the curtain:
- Alice types the message and taps send.
- Her app calls Conduit’s FastAPI endpoint with a neat little POST request.
- Conduit authenticates Alice, checks her balance (yep, billing hooks!), persists the message and the outbox event in Postgres, and returns a “got it” response.
- The Event Dispatcher sees the new outbox entry almost instantly, grabs it, and ships it to Centrifugo.
- Centrifugo broadcasts it to all subscribers of Bob’s channel over WebSockets.
- Bob’s phone buzzes. He sees “What’s up?” less than 300ms later. Conversation continues.
From Alice’s perspective, it feels magical. From our perspective, it’s patterns, queues, and a lot of testing to make sure it works under load.

Message flow from Alice to Bob
Why Conduit Matters for Customer Support
Let’s zoom out. Why sweat over this level of detail? Because in customer support, speed = trust. Nobody wants to wait 30 seconds for a reply that could’ve been instant. Nobody wants their support request lost in the ether.
With Conduit, support chats feel like texting a friend fast, real, and reliable. That’s the magic layer that makes RhythmiqCX shine. AI agents can hop in confidently, human agents can take over seamlessly, and the whole conversation flows like water.
In a world where brands live or die by customer experience, Conduit isn’t just infrastructure. It’s the heartbeat of trust.
Looking Forward
We’re not done. Conduit today is battle-ready, but tomorrow’s challenges will be tougher. More AI autonomy, more global scale, stricter compliance rules. We’re already experimenting with ways to make Conduit even smarter think adaptive load balancing, richer presence data, and tighter AI integration.
But one thing won’t change: Conduit will always be fast, reliable, and brutally honest about its limits. Because that’s what customer support deserves.
Want to Go Deeper?
If you’re as nerdy about messaging as we are, do yourself a favor and read Robin’s original write-up, which inspired this piece. Here’s the link:
Building Conduit A Scalable, Real-time messaging system - Robin Sharma