Streaming на собеседовании FAANG

Google, Meta, Amazon, Netflix - системный дизайн это половина FAANG-собеседования. Streaming вопросы: 'спроектируй YouTube Analytics', 'спроектируй notification system Uber', 'спроектируй Twitter feed'. У всех одна структура: Kafka + streaming processor + storage. Нужно знать trade-off - а не 'правильный' ответ.

• **Meta Scribe**: лог-агрегация через Kafka → Hadoop. 10TB/час. Notification system поверх: Kafka → Flink → push/email/SMS worker'ы
• **Twitter timeline**: гибридный push/pull feed. Redis Sorted Set для active users, pull для celebrities. Эволюция от монолита до streaming через 2012-2016
• **Airbnb Minerva**: real-time analytics pipeline. Kafka + Flink + Druid. 100M+ events/day. A/B тестирование результатов в real-time

Design: Notification System для 100M пользователей

Классический вопрос FAANG: спроектируй систему уведомлений как у Facebook или Twitter. Масштаб: 100M MAU, 1B уведомлений в день. Типы: push (mobile), email, SMS, in-app. Требования: delivery guarantee (at-least-once), latency < 1 сек для push, idempotency (нет дублей).

Design: News Feed для социальной сети

News feed - самый частый FAANG streaming вопрос. Twitter, Instagram, Facebook: пользователь публикует пост → фид всех подписчиков обновляется. Два подхода: Push (fanout on write): при публикации записать в фид каждого подписчика. Pull (fanout on read): фид собирается в момент чтения из постов подписок. Или гибрид.

Design: Real-time Analytics Pipeline

Типичный вопрос: спроектируй систему как Google Analytics или Amplitude - трекинг событий с real-time дашбордами. 100K event/sec, latency dashboard < 30 сек. Два слоя: hot path (streaming, минуты) и cold path (batch, часы-дни). Lambda Architecture: оба пути, результаты мержатся.

Trade-off анализ: как отвечать на FAANG interview

FAANG interviewer не ищет 'правильный' ответ - ищет структурированное мышление. Фреймворк: (1) Clarify: масштаб, SLA, консистентность нужна? (2) High-level design: нарисовать компоненты. (3) in-depth look: trade-off на каждом слое. (4) Bottleneck analysis: где узкое место при 10x нагрузке? (5) Monitoring: что мониторить, какие алерты.

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

FAANG streaming design строится на нескольких паттернах:

• CQRS Pattern — Feed: write path (Kafka fanout) и read path (Redis cache) - это CQRS
• Change Data Capture — CDC - источник событий для notification и feed систем
• Designing Systems at Scale — Backpressure и partitioning - обязательные темы в любом streaming design

Ключевые идеи

• **Notification**: Kafka fan-out → delivery workers. Redis bloom filter для dedup. Rate limiting per user. At-least-once + idempotent delivery.
• **Feed**: push (Redis Sorted Set) для обычных пользователей, pull для celebrities (>100K followers). Гибрид - стандарт.
• **Analytics**: Lambda Architecture = hot path (Flink + ClickHouse, 30 сек) + cold path (Spark + S3, часы). Оба нужны.
• **Interview фреймворк**: Clarify → High-level → in-depth look → Bottleneck 10x → Monitoring. Конкретные метрики, не абстракции.
• **Trade-off > 'правильный' ответ**: объяснить почему Kafka не RabbitMQ, когда Flink vs Spark. Это и ищет interviewer.

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

• Notification system: при падении FCM (push provider) на 30 минут - как буферизировать уведомления и избежать потери или дублирования при восстановлении?
• Feed с Redis Sorted Set: что происходит при cache miss (пользователь не заходил 30 дней)? Как построить cold cache rebuild без thundering herd?
• Lambda Architecture требует поддерживать два codebase (Flink + Spark). Когда Kappa Architecture (только streaming с replay) была бы лучше?

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

• stream-15 — Паттерны проектирования из предыдущего урока - основа interview решений
• stream-09 — Exactly-once - ключевое в notification и финансовых системах
• stream-11 — CQRS - стандартный паттерн в feed и notification системах
• stream-13 — CDC - типичный источник событий в notification pipeline
• ds-04-consistent-hashing — System design interview framework применяется и к streaming задачам
• dist-12-consistency