1 00:00:00,000 --> 00:00:01,720 Welcome back to The Deep Dive. 2 00:00:01,720 --> 00:00:05,520 Today, we are tearing apart the invisible infrastructure 3 00:00:05,520 --> 00:00:09,480 that powers everything you expect to be instant online. 4 00:00:09,480 --> 00:00:10,880 Think about watching a live event 5 00:00:10,880 --> 00:00:13,760 and seeing that comment stream just update perfectly. 6 00:00:13,760 --> 00:00:18,480 Or maybe a financial ticker that never, ever misses a beat. 7 00:00:18,480 --> 00:00:20,720 We're really talking about the engineering challenge 8 00:00:20,720 --> 00:00:23,440 behind managing millions of those persistent, 9 00:00:23,440 --> 00:00:24,920 always-on connections. 10 00:00:24,920 --> 00:00:25,880 A huge challenge. 11 00:00:25,880 --> 00:00:26,760 It really is. 12 00:00:26,760 --> 00:00:28,560 Now, before we jump into the architecture 13 00:00:28,560 --> 00:00:29,960 that makes all of that possible, 14 00:00:29,960 --> 00:00:32,040 we want to give a massive shout out to the supporter 15 00:00:32,040 --> 00:00:33,640 who helps us bring these deep dives to you. 16 00:00:33,640 --> 00:00:34,840 That's SafeServer. 17 00:00:34,840 --> 00:00:36,640 They manage high-performance hosting solutions, 18 00:00:36,640 --> 00:00:38,600 you know, exactly the kind of robust setup 19 00:00:38,600 --> 00:00:41,400 you need to run the software we're discussing today. 20 00:00:41,400 --> 00:00:43,040 So if you are serious about hosting 21 00:00:43,040 --> 00:00:44,680 and your digital transformation, 22 00:00:44,680 --> 00:00:49,680 you can find out more at www.safeserver.de. 23 00:00:49,680 --> 00:00:51,680 All right, let's unpack this mission. 24 00:00:51,680 --> 00:00:54,000 Today, we are focusing on Centrifugo. 25 00:00:54,000 --> 00:00:58,760 It's a powerful, scalable, real-time messaging server. 26 00:00:58,760 --> 00:01:03,320 And our goal today is to really get beyond the buzzwords. 27 00:01:03,320 --> 00:01:07,120 We want you to understand not just what Centrifugo is, 28 00:01:07,120 --> 00:01:09,920 but how it solves probably the biggest hurdle 29 00:01:09,920 --> 00:01:11,080 in modern applications. 30 00:01:11,080 --> 00:01:11,920 Which is? 31 00:01:11,920 --> 00:01:15,500 Managing all those massive, persistent online connections 32 00:01:15,500 --> 00:01:17,920 without forcing you to completely rewrite 33 00:01:17,920 --> 00:01:19,800 your existing application structure. 34 00:01:19,800 --> 00:01:21,160 Okay, so let's start at the very beginning. 35 00:01:21,160 --> 00:01:22,220 For anyone new to this, 36 00:01:22,220 --> 00:01:24,040 we throw around the term real-time, 37 00:01:24,040 --> 00:01:26,560 but what does that actually mean mechanically? 38 00:01:26,560 --> 00:01:27,760 That's a great question. 39 00:01:27,760 --> 00:01:29,440 It's really the difference between, say, 40 00:01:29,440 --> 00:01:32,260 a normal web request and an open phone line. 41 00:01:32,260 --> 00:01:33,100 Okay. 42 00:01:33,100 --> 00:01:35,520 A traditional web request is like you ask for data, 43 00:01:35,520 --> 00:01:37,200 the server gives it to you and then hangs up. 44 00:01:37,200 --> 00:01:39,000 You have to call back to check for updates. 45 00:01:39,000 --> 00:01:40,480 Right, the request-response cycle. 46 00:01:40,480 --> 00:01:41,560 Exactly. 47 00:01:41,560 --> 00:01:43,280 Real-time messaging is about creating 48 00:01:43,280 --> 00:01:44,720 these interactive applications 49 00:01:44,720 --> 00:01:46,760 where events or data changes 50 00:01:46,760 --> 00:01:49,520 are delivered to online users instantly 51 00:01:49,520 --> 00:01:53,360 with minimal, often imperceptible delay. 52 00:01:53,360 --> 00:01:55,000 It's like keeping that line open. 53 00:01:55,000 --> 00:01:57,400 And we used to see this in really new applications, 54 00:01:57,400 --> 00:01:59,760 but now it feels like it's absolutely everywhere. 55 00:01:59,760 --> 00:02:01,160 It is everywhere. 56 00:02:01,160 --> 00:02:03,200 It's the backbone of collaborative tools 57 00:02:03,200 --> 00:02:04,400 like Google Docs. 58 00:02:04,400 --> 00:02:07,680 It drives live sports scoreboards, live comments. 59 00:02:07,680 --> 00:02:08,640 So it's a multiplayer game. 60 00:02:08,640 --> 00:02:09,680 Multiplayer games. 61 00:02:09,680 --> 00:02:11,600 And I think most relevant for today, 62 00:02:11,600 --> 00:02:14,200 it's what enables the streaming responses 63 00:02:14,200 --> 00:02:15,480 from generative AI. 64 00:02:15,480 --> 00:02:16,520 Ah, okay. 65 00:02:16,520 --> 00:02:20,680 So when you see chat GPT typing out a response word by word. 66 00:02:20,680 --> 00:02:21,520 That's it. 67 00:02:21,520 --> 00:02:23,000 That low latency delivery is happening 68 00:02:23,000 --> 00:02:24,320 over real-time protocols. 69 00:02:24,320 --> 00:02:26,760 So if the server is keeping that connection open, 70 00:02:26,760 --> 00:02:28,880 how does the information actually flow? 71 00:02:28,880 --> 00:02:32,640 What's the fundamental mechanism here? 72 00:02:32,640 --> 00:02:36,480 The key is a pattern called PubSubs, Publish Subscribe. 73 00:02:36,480 --> 00:02:37,920 Centrifugo is specifically 74 00:02:37,920 --> 00:02:40,920 what we call a user-facing PubSub server. 75 00:02:40,920 --> 00:02:42,760 Okay, like a newspaper subscription. 76 00:02:42,760 --> 00:02:43,960 That's the perfect analogy. 77 00:02:43,960 --> 00:02:46,120 Your backend application is the publisher, 78 00:02:46,120 --> 00:02:47,440 the newspaper editor. 79 00:02:47,440 --> 00:02:50,680 When an event happens, a score changes, a new message, 80 00:02:50,680 --> 00:02:52,880 it publishes that one update to Centrifugo. 81 00:02:52,880 --> 00:02:55,080 And Centrifugo is the delivery service. 82 00:02:55,080 --> 00:02:57,320 Exactly, it automatically delivers that message 83 00:02:57,320 --> 00:03:00,560 to every single online user who is subscribed to that topic. 84 00:03:00,560 --> 00:03:03,440 That makes the logic sound simple for the backend, 85 00:03:03,440 --> 00:03:05,480 but the real hard work, the complexity, 86 00:03:05,480 --> 00:03:07,840 that's all in maintaining the connection, right? 87 00:03:07,840 --> 00:03:08,880 The transport layer. 88 00:03:08,880 --> 00:03:10,520 That's where the magic is. 89 00:03:10,520 --> 00:03:13,360 Maintaining millions of concurrent connections 90 00:03:13,360 --> 00:03:15,400 is incredibly demanding. 91 00:03:15,400 --> 00:03:17,560 Centrifugo handles all that complexity 92 00:03:17,560 --> 00:03:19,920 by supporting multiple transport protocols. 93 00:03:19,920 --> 00:03:22,320 So most people probably know WebSocket. 94 00:03:22,320 --> 00:03:24,000 Right, WebSocket is the big one. 95 00:03:24,000 --> 00:03:27,800 True bi-directional, low-latency communication, 96 00:03:27,800 --> 00:03:30,880 but it also supports things like HTTP streaming, 97 00:03:30,880 --> 00:03:33,360 server-sent events, or SSE. 98 00:03:33,360 --> 00:03:35,400 Which are more for dashboards and things, right? 99 00:03:35,400 --> 00:03:36,520 One-way updates. 100 00:03:36,520 --> 00:03:37,400 Precisely. 101 00:03:37,400 --> 00:03:39,800 And then you have gRPC and the newer 102 00:03:39,800 --> 00:03:41,200 high-performance web transport. 103 00:03:41,200 --> 00:03:43,040 It manages connections across all of these 104 00:03:43,040 --> 00:03:45,360 so your main application doesn't have to think about it. 105 00:03:45,360 --> 00:03:48,800 Which brings us directly to why this thing was even created. 106 00:03:48,800 --> 00:03:50,360 The source material says its mission 107 00:03:50,360 --> 00:03:53,280 was to wash away WebSocket scalability issues. 108 00:03:53,280 --> 00:03:54,640 And that's the pain point. 109 00:03:54,640 --> 00:03:56,900 So many developers hit a brick wall trying 110 00:03:56,900 --> 00:03:58,920 to scale persistent connections. 111 00:03:58,920 --> 00:04:01,280 Yeah, you either face huge headaches and costs, 112 00:04:01,280 --> 00:04:04,400 or you get locked into an expensive third-party service. 113 00:04:04,400 --> 00:04:07,100 Right, like Pusher or PubNub or Ably. 114 00:04:07,100 --> 00:04:10,600 Centrifugo positioned itself as the open source, 115 00:04:10,600 --> 00:04:14,240 and this is key, self-hosted alternative. 116 00:04:14,240 --> 00:04:15,640 You get that enterprise performance, 117 00:04:15,640 --> 00:04:17,840 but you control your own infrastructure. 118 00:04:17,840 --> 00:04:18,960 And it's written in Go. 119 00:04:18,960 --> 00:04:21,240 Why is that so important for a server like this? 120 00:04:21,240 --> 00:04:23,080 Oh, it's critical. 121 00:04:23,080 --> 00:04:25,640 Go was literally designed for this kind of work, 122 00:04:25,640 --> 00:04:27,640 for high concurrency networking. 123 00:04:27,640 --> 00:04:29,840 It can handle millions of connections 124 00:04:29,840 --> 00:04:32,400 using these lightweight things called Go routines 125 00:04:32,400 --> 00:04:35,680 without just drowning in memory and CPU usage. 126 00:04:35,680 --> 00:04:38,160 What I find really interesting is the integration model. 127 00:04:38,160 --> 00:04:40,080 It's totally language agnostic. 128 00:04:40,080 --> 00:04:40,580 Yes. 129 00:04:40,580 --> 00:04:44,160 Your main app could be in Python, Java, anything. 130 00:04:44,160 --> 00:04:46,880 Centrifugo just sits next to it as a separate service. 131 00:04:46,880 --> 00:04:49,520 And that architectural decoupling is the whole point. 132 00:04:49,520 --> 00:04:52,560 You're isolating the hardest problem, the real-time transport, 133 00:04:52,560 --> 00:04:55,520 into a dedicated high-performance box. 134 00:04:55,520 --> 00:04:57,920 You just tell it, hey, publish this message, 135 00:04:57,920 --> 00:04:58,960 and it handles the rest. 136 00:04:58,960 --> 00:05:01,000 So you don't have to touch your core business logic at all. 137 00:05:01,000 --> 00:05:01,560 Not at all. 138 00:05:01,560 --> 00:05:05,120 And getting started, the sources make it sound almost trivial. 139 00:05:05,120 --> 00:05:06,600 It's designed to be. 140 00:05:06,600 --> 00:05:08,560 I mean, you can get it running in seconds 141 00:05:08,560 --> 00:05:10,400 with a single Docker command, something 142 00:05:10,400 --> 00:05:12,120 like Docker runs Centrifugo. 143 00:05:12,120 --> 00:05:15,400 That low barrier to entry for such a powerful tool 144 00:05:15,400 --> 00:05:16,600 is a huge advantage. 145 00:05:16,600 --> 00:05:18,320 OK, let's talk raw power, then. 146 00:05:18,320 --> 00:05:20,720 The performance metrics in the sources 147 00:05:20,720 --> 00:05:22,880 are, frankly, pretty eye-opening. 148 00:05:22,880 --> 00:05:24,080 They really are. 149 00:05:24,080 --> 00:05:26,760 This thing shows serious industrial strength. 150 00:05:26,760 --> 00:05:30,600 It's been proven to handle 1 million concurrent web socket 151 00:05:30,600 --> 00:05:31,320 connections. 152 00:05:31,320 --> 00:05:32,720 A million connections. 153 00:05:32,720 --> 00:05:35,680 While delivering 30 million messages per minute. 154 00:05:35,680 --> 00:05:39,040 And that's on hardware that's comparable to a single modern 155 00:05:39,040 --> 00:05:39,560 server. 156 00:05:39,560 --> 00:05:40,760 That is just immense. 157 00:05:40,760 --> 00:05:44,480 And its design really focuses on that broadcast capability. 158 00:05:44,480 --> 00:05:45,160 Absolutely. 159 00:05:45,160 --> 00:05:47,720 It excels at that one-to-many scenario. 160 00:05:47,720 --> 00:05:49,160 Think of a breaking news alert. 161 00:05:49,160 --> 00:05:52,600 One piece of info needs to instantly hit millions of users. 162 00:05:52,600 --> 00:05:54,120 Centrifugo is optimized for that. 163 00:05:54,120 --> 00:05:57,120 Of course, one server can't handle a truly global scale. 164 00:05:57,120 --> 00:05:58,720 You need to scale out horizontally. 165 00:05:58,720 --> 00:05:59,200 Right. 166 00:05:59,200 --> 00:06:00,880 So how does Centrifugo achieve that? 167 00:06:00,880 --> 00:06:02,280 How do you coordinate connections 168 00:06:02,280 --> 00:06:04,480 across, say, dozens of servers? 169 00:06:04,480 --> 00:06:06,600 That's where it integrates with external brokers. 170 00:06:06,600 --> 00:06:09,080 You can run multiple Centrifugo nodes, 171 00:06:09,080 --> 00:06:12,000 and they all communicate through a reliable message broker. 172 00:06:12,000 --> 00:06:14,040 So the broker isn't talking to the user. 173 00:06:14,040 --> 00:06:16,840 It's just for the Centrifugo servers to talk to each other. 174 00:06:16,840 --> 00:06:17,880 Exactly. 175 00:06:17,880 --> 00:06:20,160 The broker is the central bulletin board. 176 00:06:20,160 --> 00:06:23,320 One node gets a message, posts it to the broker, 177 00:06:23,320 --> 00:06:25,360 and all the other nodes pick it up and deliver it 178 00:06:25,360 --> 00:06:26,960 to their connected users. 179 00:06:26,960 --> 00:06:29,320 It lets you scale out almost effortlessly. 180 00:06:29,320 --> 00:06:31,040 And what brokers does it support? 181 00:06:31,040 --> 00:06:32,200 The big ones. 182 00:06:32,200 --> 00:06:35,000 Redis, of course, and all its high-performance variants 183 00:06:35,000 --> 00:06:38,680 like AWS, ElastiCache, DragonflyDB, Valky, 184 00:06:38,680 --> 00:06:39,720 and also NATS. 185 00:06:39,720 --> 00:06:42,740 These are all battle-tested systems for this kind of work. 186 00:06:42,740 --> 00:06:45,920 What's fascinating is that they didn't just stop at speed. 187 00:06:45,920 --> 00:06:47,920 They layered on these advanced features 188 00:06:47,920 --> 00:06:51,120 that really solve real-world user experience problems. 189 00:06:51,120 --> 00:06:53,480 Yeah, this shows the maturity of the platform. 190 00:06:53,480 --> 00:06:56,160 You get flexible authentication with JWT, of course, 191 00:06:56,160 --> 00:06:58,720 but the critical features are all about data management. 192 00:06:58,720 --> 00:06:59,560 Let's talk about that, 193 00:06:59,560 --> 00:07:01,520 because nobody tolerates gaps in their sheet. 194 00:07:01,520 --> 00:07:03,360 Exactly, and that's where you get features 195 00:07:03,360 --> 00:07:06,440 like hot message history and automatic message recovery. 196 00:07:06,440 --> 00:07:08,800 So if my train goes through a tunnel and I disconnect 197 00:07:08,800 --> 00:07:09,720 for a second. 198 00:07:09,720 --> 00:07:11,240 When you reconnect, 199 00:07:11,240 --> 00:07:13,840 Centrifugo automatically checks the history buffer 200 00:07:13,840 --> 00:07:15,280 it keeps for that channel 201 00:07:15,280 --> 00:07:18,660 and instantly fills in any messages you missed. 202 00:07:18,660 --> 00:07:19,920 It's seamless for the user. 203 00:07:19,920 --> 00:07:23,000 That automatic recovery is a huge win, 204 00:07:23,000 --> 00:07:25,360 prevents so much user frustration. 205 00:07:25,360 --> 00:07:27,640 Another one is Delta compression. 206 00:07:27,640 --> 00:07:28,640 This is really clever. 207 00:07:28,640 --> 00:07:29,480 Okay. 208 00:07:29,480 --> 00:07:31,160 Imagine you're streaming a dashboard 209 00:07:31,160 --> 00:07:33,360 with hundreds of changing numbers. 210 00:07:33,360 --> 00:07:36,160 Instead of sending the full data payload every second, 211 00:07:36,160 --> 00:07:38,240 it only calculates and sends the changes, 212 00:07:38,240 --> 00:07:40,000 the Delta from the last update. 213 00:07:40,000 --> 00:07:41,860 So you're sending a few hundred bytes 214 00:07:41,860 --> 00:07:43,080 instead of a hundred kilobytes. 215 00:07:43,080 --> 00:07:45,040 That's a massive bandwidth saver. 216 00:07:45,040 --> 00:07:45,880 It's huge. 217 00:07:45,880 --> 00:07:47,760 And finally, for the application side, 218 00:07:47,760 --> 00:07:50,080 you get online presence information. 219 00:07:50,080 --> 00:07:51,900 Knowing who is currently in a channel 220 00:07:51,900 --> 00:07:53,820 with join and leave notifications 221 00:07:53,820 --> 00:07:56,200 without having to pull your database constantly. 222 00:07:56,200 --> 00:07:59,560 That feature list really proves this is battle tested stuff. 223 00:07:59,560 --> 00:08:01,480 Which brings us to reliability. 224 00:08:01,480 --> 00:08:03,120 Centrifugo started a decade ago. 225 00:08:03,120 --> 00:08:03,960 It's mature. 226 00:08:03,960 --> 00:08:04,780 Oh yeah. 227 00:08:04,780 --> 00:08:06,160 It's an option by massive companies. 228 00:08:06,160 --> 00:08:09,960 We're talking about VK, Badoo, ManyChat, OpenWeb, 229 00:08:09,960 --> 00:08:11,080 even Grafana. 230 00:08:11,080 --> 00:08:13,360 Services where lag is just not an option. 231 00:08:13,360 --> 00:08:15,640 That has to give developers a lot of confidence. 232 00:08:15,640 --> 00:08:17,320 And there are great testimonials too, 233 00:08:17,320 --> 00:08:19,080 like from Victor Pontus at Luma. 234 00:08:19,080 --> 00:08:22,840 He said it's been incredibly easy to use and reliable. 235 00:08:22,840 --> 00:08:24,560 And if you want to see its speed in action, 236 00:08:24,560 --> 00:08:27,600 there's a demo where it streams telemetry data 237 00:08:27,600 --> 00:08:29,960 from the Assetto Corsa Racing Simulator 238 00:08:29,960 --> 00:08:34,080 to a Grafana dashboard at 60 updates per second. 239 00:08:34,080 --> 00:08:34,840 60 hertz. 240 00:08:34,840 --> 00:08:36,660 A 60 hertz update rate. 241 00:08:36,660 --> 00:08:38,080 That's the kind of responsiveness 242 00:08:38,080 --> 00:08:39,440 modern data apps need. 243 00:08:39,440 --> 00:08:42,000 Now, it's open source, but there's also 244 00:08:42,000 --> 00:08:45,160 an enterprise option, Centrifugo PRO. 245 00:08:45,160 --> 00:08:46,680 What does that bring to the table? 246 00:08:46,680 --> 00:08:50,000 The PRO version basically takes that high-performance engine 247 00:08:50,000 --> 00:08:53,120 and wraps it with the features that large organizations need. 248 00:08:53,120 --> 00:08:55,540 It's all about observability and management. 249 00:08:55,540 --> 00:08:58,000 So things like analytics, tracing. 250 00:08:58,000 --> 00:08:58,760 Exactly. 251 00:08:58,760 --> 00:09:01,160 Analytics with ClickHouse, real-time tracing 252 00:09:01,160 --> 00:09:04,040 for debugging, a push notification API, 253 00:09:04,040 --> 00:09:06,760 and crucial SSO integrations for the web UI. 254 00:09:06,760 --> 00:09:09,920 So if the open source version is the high-speed engine, 255 00:09:09,920 --> 00:09:11,880 PRO is like the corporate cockpit 256 00:09:11,880 --> 00:09:14,600 with all the detailed telemetry and compliance tools. 257 00:09:14,600 --> 00:09:15,880 That's a perfect way to put it. 258 00:09:15,880 --> 00:09:18,440 Let's big companies host this critical infrastructure 259 00:09:18,440 --> 00:09:21,400 themselves, but still get the management tools they need. 260 00:09:21,400 --> 00:09:24,180 So after diving deep into all this, 261 00:09:24,180 --> 00:09:26,760 what's the ultimate takeaway for you, the listener? 262 00:09:26,760 --> 00:09:29,400 For me, what's fascinating is that Centrifugo 263 00:09:29,400 --> 00:09:32,560 offers this robust, high-performance, 264 00:09:32,560 --> 00:09:35,080 and critically self-hosted solution. 265 00:09:35,080 --> 00:09:37,560 It lets you decouple that hardest piece of scaling, 266 00:09:37,560 --> 00:09:40,360 the connection management, and add real-time features 267 00:09:40,360 --> 00:09:43,280 to any application using proven, mature software. 268 00:09:43,280 --> 00:09:46,040 So if you're even thinking about scaling real-time features, 269 00:09:46,040 --> 00:09:48,320 a messenger, a data stream, whatever it is, 270 00:09:48,320 --> 00:09:51,160 this shows that you can own that complex transport layer 271 00:09:51,160 --> 00:09:54,120 and gain massive, proven performance. 272 00:09:54,120 --> 00:09:55,840 And let's end on a provocative thought. 273 00:09:55,840 --> 00:09:58,760 The sources mentioned using this for streaming AI responses. 274 00:09:58,760 --> 00:09:59,260 Right. 275 00:09:59,260 --> 00:10:02,440 Just consider the absolute explosion of generative AI. 276 00:10:02,440 --> 00:10:05,680 All of it relies on instant character-by-character output 277 00:10:05,680 --> 00:10:06,360 streams. 278 00:10:06,360 --> 00:10:09,440 That makes these specialized high-throughput message servers 279 00:10:09,440 --> 00:10:12,600 not just a nice-to-have, but absolutely essential 280 00:10:12,600 --> 00:10:16,160 infrastructure for the future of any app using AI. 281 00:10:16,160 --> 00:10:18,560 Infrastructure is always the key. 282 00:10:18,560 --> 00:10:21,480 A big thank you once again to our supporter, Safe Server, 283 00:10:21,480 --> 00:10:23,440 for powering this deep dive. 284 00:10:23,440 --> 00:10:25,520 They really understand the demands of running 285 00:10:25,520 --> 00:10:26,680 complex software like this. 286 00:10:26,680 --> 00:10:28,400 You can learn more about how they can help 287 00:10:28,400 --> 00:10:33,080 manage your next deployment at www.safeserver.de. 288 00:10:33,080 --> 00:10:34,920 Until next time, keep digging deeper. 289 00:10:34,920 --> 00:10:36,760 See you soon.