Компьютерные сети

System Design: Network Cases

System design интервью - это не про memorization, это про демонстрацию инженерного мышления. Networking layer - часто упускаемый, но критичный аспект: какой протокол, как scale connections, где cache.

  • **WhatsApp**: 2B users, millions of concurrent WebSocket connections, push model for delivery
  • **Twitter**: hybrid fanout, celebrity problem, Redis для timelines, Kafka для event sourcing
  • **Netflix**: CDN первого уровня, adaptive bitrate, 15% мирового internet traffic

Предварительные знания

  • What happens when you type google.com
  • Rate Limiting
  • Consistent Hashing

Цели урока

  • Структурировать ответ system design: requirements → estimation → API → data model → networking → bottlenecks → trade-offs
  • Выбирать протокол: WebSocket для bidirectional, SSE для server-push, long polling как fallback, gRPC для internal RPC
  • Прикидывать порядки: 2B users → ~50M concurrent → разнести по 100K conn/box = 500 boxes
  • Применять networking blocks: load balancer L4 vs L7, CDN edge, rate limiter с token bucket, consistent hashing для shards
  • Идентифицировать celebrity problem, hot keys, thundering herd и предлагать конкретные митигации

Design: Chat System

**Design Chat (WhatsApp/Slack)** - классический system design вопрос. Фокус на real-time delivery, online presence, message ordering, scaling WebSocket connections.

**Redis Pub/Sub** для fan-out: когда user A на Server1 отправляет user B на Server2, Redis доставляет сообщение. Каждый WS server подписан на каналы своих connected users.

Ключевые решения: **sticky sessions** для WebSocket (user всегда на том же сервере), **message ordering** (sequence numbers, server-side timestamps), **offline delivery** (store and forward).

Как доставить сообщение пользователю на другом WebSocket сервере?

Design: Twitter Feed

**Design Twitter Timeline** - про fanout: когда celebrity с 10M followers постит tweet, как доставить всем? Trade-off между push (fanout on write) и pull (fanout on read).

**Redis Sorted Sets** для timeline cache: ZADD timeline:userA timestamp tweetId. ZRANGE для получения последних N tweets. Score = timestamp для сортировки.

Network aspects: **CDN** для media (images, videos), **sharding** tweets по userId (consistent hashing), **caching** hot tweets, **rate limiting** на post frequency.

Почему Twitter использует hybrid fanout вместо pure push?

Design: Video Streaming

**Design YouTube/Netflix** - про efficient video delivery: CDN, adaptive bitrate, chunked transfer. Network - критический компонент для buffering-free experience.

**HLS vs DASH**: HLS (Apple) использует .ts segments, DASH (Google) использует .mp4. Оба поддерживают adaptive bitrate. HLS более распространён из-за iOS.

CDN - ключ к масштабированию. Popular videos кешируются на edge (~95% cache hit). Origin handle только редкие/новые videos. Regional POPs минимизируют latency.

Почему video разбивается на chunks (segments)?

Design: Notification System

**Design Notification System** - multi-channel delivery (push, email, SMS, in-app). Про message queues, rate limiting, user preferences, delivery guarantees.

**At-least-once delivery**: Kafka consumer commits offset after sending. При crash - re-process. Idempotency key предотвращает duplicate notifications.

Network considerations: **FCM/APNS** имеют rate limits и retry logic. **Webhook endpoints** для third-party. **Exponential backoff** при failures. **Priority queues** для critical vs marketing.

Почему notification system использует отдельные queues per channel?

Interview Framework

System design интервью оценивает мышление, не memorized answers. Следуйте структуре: clarify requirements, estimate scale, design high-level, deep dive on components, discuss trade-offs.

**Network layer questions** часто упускаются. Proactively discuss: какой протокол (HTTP vs WebSocket vs gRPC), как handle failures (retry, circuit breaker), caching strategy, CDN for static.

Show trade-offs thinking: "Push simplifies reads but Celebrity problem. Pull scales writes but slow reads. I'd use hybrid." Интервьюер хочет видеть reasoning, не идеальный ответ.

System design - про запоминание архитектур известных систем

System design - про демонстрацию структурного мышления: clarify → estimate → design → trade-offs. Интервьюер оценивает процесс принятия решений, не 'правильный' ответ

Нет единственного правильного дизайна. Twitter, Instagram, WhatsApp - все по-разному решают похожие проблемы. Важно обосновать ваш выбор для конкретных requirements.

Почему back-of-envelope estimation важна на system design интервью?

Итоги

  • **Chat**: WebSocket + Pub/Sub для cross-server delivery, sticky sessions для connection affinity
  • **Feed**: Push для обычных users, Pull для celebrities, Redis sorted sets для timeline
  • **Video**: Chunked streaming, adaptive bitrate, CDN caching, HLS/DASH manifest
  • **Notifications**: Message queues, channel isolation, rate limiting, at-least-once delivery
  • **Interview**: Clarify → Estimate → Design → Deep dive → Trade-offs

Связанные темы

Этот урок интегрирует всё, что изучено ранее:

  • Real-time Protocols — WebSocket vs SSE vs Polling для chat/notifications
  • Consistent Hashing — Sharding messages/users across servers
  • Latency Numbers — Back-of-envelope estimation requires knowing these

Вопросы для размышления

  • Как бы вы спроектировали live streaming (Twitch) с миллионом concurrent viewers?
  • Какие network trade-offs при выборе gRPC vs REST для микросервисов?
  • Как обеспечить exactly-once delivery в distributed notification system?

Связанные уроки

  • sd-01-intro
System Design: Network Cases

0

1

Войти