After the Discord system design diagram was posted, the comments first asked about Redis TTL

Suni posted a Discord System Design architecture diagram on X, with only this one line of caption. The diagram was drawn with Excalidraw, as he said in a reply. The diagram is as follows:

In the comments, Franciele raised a specific question: storing presence in Redis with a TTL is risky—if the user is still connected, could their status expire and disappear first? This wasn't expanded on. A reply later said, "No, it's not," and someone else just replied "Important." Another user said that after ten years, messages still sometimes disappear. Someone else joked that everything has to be rebuilt in Rust.

These replies are more interesting than the diagram itself. System design diagrams easily turn into boxes and arrows; what actually breaks first in production is often the edge cases around expiration times, presence, and message reachability. Putting presence in Redis isn't strange, and TTL isn't strange either; the tricky part is how to align TTL with the connection lifecycle. The connection is still there, but the status disappears first—what the user sees is "I'm clearly online, but others see me as offline." This kind of problem isn't answered by an architecture diagram; it's answered by heartbeats, renewals, disconnect callbacks, and fallback strategies.

Suni's tweet also cited an external link titled "Instagram system design: a fan and a star, then one story to 184 friends." The external link breaks down the call order for a follow, viewing a Story, liking, and commenting. Several details are worth looking at: Virat's profile reads from Memcache instead of hitting the database directly; a follow writes two rows, landing in two users' shards; Stories use write fan-out for ordinary users—184 followers means writing 184 trays—while for an account with 273 million followers, it switches to pull and does not copy; like counts are split into multiple small counters and added up on read; notifications are merged by time window rather than pushed one by one; comments first go through Safety before being written to the database. The external link also mentions that Story view records are written to Cassandra—one million views means one million rows, not one million notifications.

These details are the same kind of thing as the TTL question under the Discord diagram: read/write paths, caching, expiration, counting, and notification aggregation determine whether a system holds up in the hands of real users. A good-looking diagram is the entry point; that question in the comments is the hook that keeps you reading.

External link: https://sd-for-rookies.tech/instagram