@hackproduct9: One post. Eighteen moving parts. This is what actually happens when you tap "Share." 🌐 GETTING IN Client hits DNS to find the nearest edge. Static content — photos, JS, video — comes straight off the CDN and never touches your servers. Everything else goes to a load balancer, then through API gateways. Then a SECOND load balancer, and this one matters: it splits traffic into APP READ servers and APP WRITE servers. Different machines. Different scaling. Reads outnumber writes 100 to 1, so they cannot share a box. ✍️ THE WRITE SIDE Write server drops jobs onto queues instead of doing them inline. Video goes to the video queue → processing service → a pool of workers. The post goes to the feed gen queue → Feed Generation Service. Nothing slow happens while the user is waiting. That's the whole reason queues exist here. 👀 THE READ SIDE Read server hits CACHE first, always. Cache miss → Metadata/User DB, which is sharded: a Shard Manager and directory-based partitioning decide which box holds which user. Master takes writes, slaves serve reads. Search is its own path entirely — aggregator → search index with its own caches. You do not run text search against your primary database. 🔔 THE LOOPS Feed Generation writes back to the DB and fires the notification queue. Those two red lines wrapping the diagram are the async tails — the work that finishes after you've already seen "Posted." THE RULE: split reads from writes. Then shard. The failure mode: one app server doing both. It works at 10k users and falls over at 10 million, because your read traffic and your write traffic need opposite things — caching versus consistency. 📸 Screenshot this before your next system design interview. Follow @hackproduct ⚡ . . #systemdesign #systemdesigninterview #softwareengineering #facebook #backenddevelopment

HackProduct

Open In TikTok:

Region: US

Sunday 20 September 2026 22:56:18 GMT