Today's Deep-Dive: Centrifugo

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.

See you soon.

See you soon.