Most software design conversations jump straight to code. Our third YozmaTalk started somewhere else entirely — a restaurant at 8pm rush hour — and used it to explain why some systems handle millions of users while others fall apart under load.

Peto Sefilian — a senior engineer who works with system design daily — walked us through the fundamentals of designing scalable, reliable software, translating every concept from a real-life restaurant example into the architecture behind a TikTok-style video platform.

What we covered

The session opened with a simple idea: system design is not about drawing boxes on a diagram. Drawing boxes is the visible part — the real work is making trade-offs. A system that must respond in 100 milliseconds is designed differently from one where a 10-second response is fine; a system that must survive a data center failure looks nothing like a small internal admin tool.

Peto used a restaurant at rush hour to make these trade-offs concrete before touching any technical terms: one kitchen, one cook, and one courier work fine when traffic is low, but a broken oven becomes a single point of failure, a slow kitchen becomes high latency, and too many orders arriving at once becomes a throughput problem. Every core system design concept — horizontal and vertical scaling, replicas, load balancing, queues, caching — mapped directly onto something happening in that kitchen.

The live build: designing a video platform

The core of the session was translating those same restaurant concepts into the architecture of a TikTok- or Instagram-style video platform, built live from requirements to diagram. Peto started with functional requirements (upload, feed, likes, comments, recommendations, moderation) and then walked through capacity estimation — the step he called the most important part of system design, because rough numbers are what actually drive architecture decisions rather than guesses.

With 50 million daily active users watching 100 videos a day, the math lands around 58,000 video views per second on average, spiking to roughly 290,000 at peak. On the upload side, even a modest 1% upload rate works out to around 10 terabytes of raw video a day before replicas or transcoded versions — which is exactly why video bytes get served from object storage and a CDN, never from the application servers directly.

From there, Peto broke down the full architecture: an API gateway handling auth and rate limiting, separate services for uploads, feed, interactions, users, and recommendations, a message queue (Kafka or SQS) for heavy asynchronous work like transcoding and moderation, a metadata database with sharding and read replicas, Redis for caching precomputed feeds, and a CDN serving video bytes from edge locations close to users.

Replicas, consistency, and what’s allowed to lag

One of the sharper points of the talk: not every part of a system needs the same consistency model. Writes go to the primary database, reads can go to replicas — and if the primary fails, a replica gets promoted. But replicas lag, which means some data (like counts, likes, analytics) can safely be eventually consistent, while other data (payments, wallet balances, account security) cannot. Good system design means choosing the right consistency level per feature, not applying one rule everywhere.

Designing for failure and traffic spikes

Peto also covered what happens when a celebrity posts and traffic spikes without warning: rate limiting at the gateway as the first line of defense, load balancers routing around unhealthy replicas, and queues absorbing bursts so background workers can catch up at a safe pace instead of forcing everything to happen synchronously. When a queue backs up, that’s the signal to add more workers.

Just as important as building the system is watching it: logs answer what happened, metrics answer how much and how fast, distributed tracing shows which step in a request chain is slow, and alerts catch serious conditions — like replica lag exceeding a set threshold — before users start complaining.

Key takeaways

• Start with requirements — both functional (what the system should do) and non-functional (latency, reliability, consistency expectations)
• Capacity estimation comes before architecture — rough numbers beat guesses when deciding on storage, servers, and scaling
• Design for latency using caching, CDNs, replicas, and precomputation — average latency can hide a bad experience for a meaningful slice of users
• Design for failure — assume components will break, and build in replicas, failover, retries, and backups from the start
• Separate responsibilities into services with clear ownership and clear APIs; push heavy work onto asynchronous queues
• Measure everything — logs, metrics, tracing, and alerts close the feedback loop and catch problems before users do
• The question worth asking about any system: what breaks first when traffic becomes 10 times bigger?