IndiGo is India’s largest airline by market share, operating hundreds of flights daily across domestic and international routes. If you’ve ever booked a flight on goindigo.in or the IndiGo app, you interacted with one of the most sophisticated transactional systems in the country — a system that has to handle millions of searches, coordinate real-time inventory across thousands of flights, process payments securely, and issue legally valid tickets, all within a few seconds.

Airline reservation systems are not just booking systems. They are distributed systems problems at scale, with real money, real people, and legally binding contracts involved. A failed payment that results in a confirmed seat is a liability. A double-booked seat is a disaster. A slow search experience sends users to a competitor. The stakes are incredibly high.

What makes airline booking particularly hard compared to, say, an e-commerce system? In e-commerce, you can slightly oversell and manage the backorder. In airline booking, there is no backorder. If seat 14A on flight 6E-205 departing Mumbai at 8:30 AM is sold, it is sold. You cannot manufacture another 14A. Inventory is finite, time-bounded, and irreplaceable.

There is a common belief in software engineering circles that relational databases cannot scale. The moment you say “MySQL” in a room full of distributed systems engineers, someone will inevitably raise an eyebrow and say “that won’t hold up at scale.” YouTube’s story is one of the most powerful counterarguments to that assumption. At the time of its acquisition by Google in 2006, YouTube was already one of the fastest-growing websites on the internet. And it was running on MySQL.

Understanding how YouTube built and scaled its database infrastructure is not just a historical curiosity. It is a practical masterclass in how thoughtful engineers take ordinary tools and stretch them far beyond what anyone thought possible. The lessons here apply directly to the systems you are building today.

The Scale of the Problem

Let’s ground this with numbers. YouTube launched in 2005. Within six months it was serving more than two million video views per day. By 2006, that number had climbed to over 100 million views per day. Google acquired it for $1.65 billion in October of that year. By 2012, more than 72 hours of video were being uploaded every minute. Today that number exceeds 500 hours per minute.

There is a version of the AI story that goes like this: companies saw ChatGPT, realized the future had arrived, moved fast, deployed AI everywhere, and transformed their businesses. That version makes for good investor decks. The reality is messier, more expensive, and far more interesting.

What actually happened is that almost every company launched AI initiatives simultaneously, many of them with very little understanding of what production AI systems actually cost, how they behave at scale, and what it takes to keep them reliable. The gap between the AI demo and the AI production system turned out to be enormous. And most enterprises are still in the process of figuring out how to close that gap.

This piece is not about whether AI is real or valuable. It is. This is about understanding what building serious AI systems inside a company actually requires, what it costs, what breaks, and what you should be thinking about if you are an engineer, architect, or technology leader trying to navigate this space honestly.

The Rush That Started Everything

When OpenAI released ChatGPT in late 2022, something unusual happened in the enterprise technology world. Usually, new platforms take years to reach boardroom-level urgency. Cloud computing took most of the 2000s to become a board-level concern. Mobile took years after the iPhone before enterprise IT leaders were forced to take it seriously. AI did not have that grace period.

There is a version of Slack that most engineers imagine when they first think about how it works. You type a message, hit Enter, and it shows up on someone else’s screen. Simple enough. But the moment you start pulling at the threads of that interaction, things get complicated fast. What happens when a thousand people are in the same channel? What happens when someone is on mobile with spotty connectivity? What happens when your company has 80,000 employees and legal needs a full audit trail of every message sent over the last three years?

Slack is not just a chat application. It is a distributed, event-driven, real-time collaboration platform operating at a scale where individual engineering decisions ripple out into millions of daily user experiences. It handles hundreds of millions of messages per day, maintains persistent WebSocket connections for millions of concurrent users, and does all of this while offering sub-second message delivery, reliable push notifications, full-text search across years of history, and enterprise-grade security.

Building any one of those systems in isolation is a meaningful engineering problem. Building them together, making them interact reliably under load, and then keeping them running around the clock for paying enterprise customers is a genuinely difficult distributed systems challenge. This blog is about how that all works.

We will move from the high-level shape of the system down into the guts of individual subsystems. Some sections will feel like a system design interview. Others will feel like a postmortem. That is intentional. The goal is not just to understand Slack academically but to develop real engineering instincts about why real-time collaboration platforms are designed the way they are.

Core Features of Slack

Before diving into the architecture, it helps to enumerate what the system actually needs to do. Engineers sometimes skip this step and then wonder why their schema does not support threads or why their fanout logic breaks on large channels.

There is a small white disc sitting on your key ring right now. It weighs eleven grams. It has no GPS chip, no cellular radio, and no Wi-Fi antenna. Its battery lasts over a year. And yet, if you drop your keys somewhere in downtown Tokyo, there is a very good chance you will get an accurate location update within minutes, without Apple ever knowing where your keys are.

That combination of properties is not magic. It is one of the most carefully engineered consumer-scale distributed systems in the world, and the design decisions behind it touch almost every interesting area of modern infrastructure: Bluetooth Low Energy networking, end-to-end encrypted relay systems, crowd-sourced location discovery, ultra-wideband spatial positioning, privacy-preserving cryptography, and a globally distributed event pipeline spanning hundreds of millions of devices.

This blog walks through the full internal architecture of Apple AirTags, from the radio signals pulsing out of the hardware to the cloud infrastructure that receives, processes, and delivers location events back to owners. By the end, you should understand not just what AirTags do, but why each system is designed the way it is, what the tradeoffs are, and how this infrastructure scales to a network of over a billion Apple devices.

What Apple AirTags Are and Why They Matter

Before AirTags, tracking a lost item typically meant relying on GPS. GPS trackers work reasonably well outdoors but require cellular or Wi-Fi connectivity to upload their position, have batteries measured in days or weeks, and broadcast their presence loudly to anyone listening. They also cost more, require SIM cards in some cases, and fundamentally cannot work indoors where GPS signals are too weak.

AirTags sidestep all of that. Instead of using their own GPS or cellular connection, they hitchhike on the massive installed base of Apple devices around them. An AirTag sitting inside a bag on a train broadcasts a short Bluetooth Low Energy advertisement packet. Every iPhone and iPad nearby receives that advertisement, silently looks up the AirTag’s rotating public key, uses it to encrypt the current GPS position of the iPhone, and uploads that encrypted blob to Apple’s servers. The AirTag’s owner can then download that blob, decrypt it with the matching private key that only they hold, and recover the location.