Welcome back to The Deep Dive.
Today, we are tearing apart the invisible infrastructure
that powers everything you expect to be instant online.
Think about watching a live event
and seeing that comment stream just update perfectly.
Or maybe a financial ticker that never, ever misses a beat.
We're really talking about the engineering challenge
behind managing millions of those persistent,
always-on connections.
A huge challenge.
It really is.
Now, before we jump into the architecture
that makes all of that possible,
we want to give a massive shout out to the supporter
who helps us bring these deep dives to you.
That's SafeServer.
They manage high-performance hosting solutions,
you know, exactly the kind of robust setup
you need to run the software we're discussing today.
So if you are serious about hosting
and your digital transformation,
you can find out more at www.safeserver.de.
All right, let's unpack this mission.
Today, we are focusing on Centrifugo.
It's a powerful, scalable, real-time messaging server.
And our goal today is to really get beyond the buzzwords.
We want you to understand not just what Centrifugo is,
but how it solves probably the biggest hurdle
in modern applications.
Which is?
Managing all those massive, persistent online connections
without forcing you to completely rewrite
your existing application structure.
Okay, so let's start at the very beginning.
For anyone new to this,
we throw around the term real-time,
but what does that actually mean mechanically?
That's a great question.
It's really the difference between, say,
a normal web request and an open phone line.
Okay.
A traditional web request is like you ask for data,
the server gives it to you and then hangs up.
You have to call back to check for updates.
Right, the request-response cycle.
Exactly.
Real-time messaging is about creating
these interactive applications
where events or data changes
are delivered to online users instantly
with minimal, often imperceptible delay.
It's like keeping that line open.
And we used to see this in really new applications,
but now it feels like it's absolutely everywhere.
It is everywhere.
It's the backbone of collaborative tools
like Google Docs.
It drives live sports scoreboards, live comments.
So it's a multiplayer game.
Multiplayer games.
And I think most relevant for today,
it's what enables the streaming responses
from generative AI.
Ah, okay.
So when you see chat GPT typing out a response word by word.
That's it.
That low latency delivery is happening
over real-time protocols.
So if the server is keeping that connection open,
how does the information actually flow?
What's the fundamental mechanism here?
The key is a pattern called PubSubs, Publish Subscribe.
Centrifugo is specifically
what we call a user-facing PubSub server.
Okay, like a newspaper subscription.
That's the perfect analogy.
Your backend application is the publisher,
the newspaper editor.
When an event happens, a score changes, a new message,
it publishes that one update to Centrifugo.
And Centrifugo is the delivery service.
Exactly, it automatically delivers that message
to every single online user who is subscribed to that topic.
That makes the logic sound simple for the backend,
but the real hard work, the complexity,
that's all in maintaining the connection, right?
The transport layer.
That's where the magic is.
Maintaining millions of concurrent connections
is incredibly demanding.
Centrifugo handles all that complexity
by supporting multiple transport protocols.
So most people probably know WebSocket.
Right, WebSocket is the big one.
True bi-directional, low-latency communication,
but it also supports things like HTTP streaming,
server-sent events, or SSE.
Which are more for dashboards and things, right?
One-way updates.
Precisely.
And then you have gRPC and the newer
high-performance web transport.
It manages connections across all of these
so your main application doesn't have to think about it.
Which brings us directly to why this thing was even created.
The source material says its mission
was to wash away WebSocket scalability issues.
And that's the pain point.
So many developers hit a brick wall trying
to scale persistent connections.
Yeah, you either face huge headaches and costs,
or you get locked into an expensive third-party service.
Right, like Pusher or PubNub or Ably.
Centrifugo positioned itself as the open source,
and this is key, self-hosted alternative.
You get that enterprise performance,
but you control your own infrastructure.
And it's written in Go.
Why is that so important for a server like this?
Oh, it's critical.
Go was literally designed for this kind of work,
for high concurrency networking.
It can handle millions of connections
using these lightweight things called Go routines
without just drowning in memory and CPU usage.
What I find really interesting is the integration model.
It's totally language agnostic.
Yes.
Your main app could be in Python, Java, anything.
Centrifugo just sits next to it as a separate service.
And that architectural decoupling is the whole point.
You're isolating the hardest problem, the real-time transport,
into a dedicated high-performance box.
You just tell it, hey, publish this message,
and it handles the rest.
So you don't have to touch your core business logic at all.
Not at all.
And getting started, the sources make it sound almost trivial.
It's designed to be.
I mean, you can get it running in seconds
with a single Docker command, something
like Docker runs Centrifugo.
That low barrier to entry for such a powerful tool
is a huge advantage.
OK, let's talk raw power, then.
The performance metrics in the sources
are, frankly, pretty eye-opening.
They really are.
This thing shows serious industrial strength.
It's been proven to handle 1 million concurrent web socket
connections.
A million connections.
While delivering 30 million messages per minute.
And that's on hardware that's comparable to a single modern
server.
That is just immense.
And its design really focuses on that broadcast capability.
Absolutely.
It excels at that one-to-many scenario.
Think of a breaking news alert.
One piece of info needs to instantly hit millions of users.
Centrifugo is optimized for that.
Of course, one server can't handle a truly global scale.
You need to scale out horizontally.
Right.
So how does Centrifugo achieve that?
How do you coordinate connections
across, say, dozens of servers?
That's where it integrates with external brokers.
You can run multiple Centrifugo nodes,
and they all communicate through a reliable message broker.
So the broker isn't talking to the user.
It's just for the Centrifugo servers to talk to each other.
Exactly.
The broker is the central bulletin board.
One node gets a message, posts it to the broker,
and all the other nodes pick it up and deliver it
to their connected users.
It lets you scale out almost effortlessly.
And what brokers does it support?
The big ones.
Redis, of course, and all its high-performance variants
like AWS, ElastiCache, DragonflyDB, Valky,
and also NATS.
These are all battle-tested systems for this kind of work.
What's fascinating is that they didn't just stop at speed.
They layered on these advanced features
that really solve real-world user experience problems.
Yeah, this shows the maturity of the platform.
You get flexible authentication with JWT, of course,
but the critical features are all about data management.
Let's talk about that,
because nobody tolerates gaps in their sheet.
Exactly, and that's where you get features
like hot message history and automatic message recovery.
So if my train goes through a tunnel and I disconnect
for a second.
When you reconnect,
Centrifugo automatically checks the history buffer
it keeps for that channel
and instantly fills in any messages you missed.
It's seamless for the user.
That automatic recovery is a huge win,
prevents so much user frustration.
Another one is Delta compression.
This is really clever.
Okay.
Imagine you're streaming a dashboard
with hundreds of changing numbers.
Instead of sending the full data payload every second,
it only calculates and sends the changes,
the Delta from the last update.
So you're sending a few hundred bytes
instead of a hundred kilobytes.
That's a massive bandwidth saver.
It's huge.
And finally, for the application side,
you get online presence information.
Knowing who is currently in a channel
with join and leave notifications
without having to pull your database constantly.
That feature list really proves this is battle tested stuff.
Which brings us to reliability.
Centrifugo started a decade ago.
It's mature.
Oh yeah.
It's an option by massive companies.
We're talking about VK, Badoo, ManyChat, OpenWeb,
even Grafana.
Services where lag is just not an option.
That has to give developers a lot of confidence.
And there are great testimonials too,
like from Victor Pontus at Luma.
He said it's been incredibly easy to use and reliable.
And if you want to see its speed in action,
there's a demo where it streams telemetry data
from the Assetto Corsa Racing Simulator
to a Grafana dashboard at 60 updates per second.
60 hertz.
A 60 hertz update rate.
That's the kind of responsiveness
modern data apps need.
Now, it's open source, but there's also
an enterprise option, Centrifugo PRO.
What does that bring to the table?
The PRO version basically takes that high-performance engine
and wraps it with the features that large organizations need.
It's all about observability and management.
So things like analytics, tracing.
Exactly.
Analytics with ClickHouse, real-time tracing
for debugging, a push notification API,
and crucial SSO integrations for the web UI.
So if the open source version is the high-speed engine,
PRO is like the corporate cockpit
with all the detailed telemetry and compliance tools.
That's a perfect way to put it.
Let's big companies host this critical infrastructure
themselves, but still get the management tools they need.
So after diving deep into all this,
what's the ultimate takeaway for you, the listener?
For me, what's fascinating is that Centrifugo
offers this robust, high-performance,
and critically self-hosted solution.
It lets you decouple that hardest piece of scaling,
the connection management, and add real-time features
to any application using proven, mature software.
So if you're even thinking about scaling real-time features,
a messenger, a data stream, whatever it is,
this shows that you can own that complex transport layer
and gain massive, proven performance.
And let's end on a provocative thought.
The sources mentioned using this for streaming AI responses.
Right.
Just consider the absolute explosion of generative AI.
All of it relies on instant character-by-character output
streams.
That makes these specialized high-throughput message servers
not just a nice-to-have, but absolutely essential
infrastructure for the future of any app using AI.
Infrastructure is always the key.
A big thank you once again to our supporter, Safe Server,
for powering this deep dive.
They really understand the demands of running
complex software like this.
You can learn more about how they can help
manage your next deployment at www.safeserver.de.
Until next time, keep digging deeper.
See you soon.