Канат изучает систем дизайн и решает алгосы

Одна из самых интересных задач в моей жизни в разработке. В начале моей карьеры когда я работал в Aviata (Freedom Travel) была проблема с тем что из большинства небольших городов в западные страны нет рейсов. О том как я решил это разобрал в этой статье

Бесплатная неделя claude pro от меня, есть 3 активации

https://claude.ai/referral/DEjgxf0FOQ?s=ios

Если клод вам тоже инвайты дал, можете делится в комментариях

Написал article на тему
Вебсокеты в system design интервью: когда они действительно нужны
Буду рад комментариям!
In english
На русском

На Pycon дали бесплатный месяц подписки Claude Max, работает только если у вас аккаунт США

На PyCon больше всего запомнился доклад про новый профайлер Python - Tachyon (Python 3.15).

До этого встроенное профилирование в основном ассоциировалось с cProfile: очень точный инструмент, но он вмешивается в работу программы, потому что отслеживает каждый вызов функции.

Tachyon работает по-другому - через sampling. Он периодически снимает стек вызовов, почти не влияет на производительность и может подключаться к уже работающему процессу.

Допустим, ваш сервис крутится на Python 3.11 в проде. Вам не нужно обновлять его до 3.15, чтобы воспользоваться новым профайлером. Можно подключиться к уже запущенному процессу и посмотреть, где он реально проводит время.

Что понравилось:
— встроен в Python;
— минимальный overhead;
— flame graphs из коробки;
— можно профилировать уже работающие процессы;
— подходит для анализа живых сервисов;
— работает даже если сам сервис запущен не на Python 3.15.

Кажется, это один из самых полезных инструментов, которые появились в экосистеме Python за последнее время. Раньше за подобными возможностями многие шли к py-spy и другим сторонним решениям, теперь это появляется прямо в стандартной библиотеке.

At-Least-Once vs Exactly-Once в Kafka: чему нас учит опыт FAANG? В теории архитектуры распределенных систем «честный» Exactly-Once (EOS) в Kafka часто называют священным граалем. Но если заглянуть под капот архитектуры бигтеха, выясняется неожиданное: инженеры FAANG до последнего избегают встроенного Exactly-Once. Почему так и как гиганты решают проблему дубликатов на объемах в петабайты? Разбираем на реальных кейсах.

🚀 Как это делают в FAANG: Реальные кейсы
1. Uber: Идемпотентность на уровне хранилища (At-Least-Once)
В Uber инженеры открыто говорят: удерживать ACID-транзакции на их масштабах — утопия. Для обработки поездок и платежей они используют связку Kafka + At-Least-Once + собственная база данных Schemaless (на базе MySQL).

Как это работает: Каждому событию (например, запросу на списание денег) присваивается UUID еще на клиенте. В БД строка пишется через INSERT ... ON CONFLICT DO NOTHING. Если из-за сетевого сбоя Kafka доставит инвойс дважды, база данных просто проигнорирует второй запрос. Нагрузка ложится на индексы БД, зато сама Kafka летит с максимальной скоростью.

2. Netflix: Миллиарды событий в секунду (At-Most-Once)
Для рекомендательной системы и сбора логов Netflix выбирает... потерю данных. Их стриминговая платформа Keystone обрабатывает более 500 миллиардов событий в день.

Как это работает: Если вы мотаете сериал и плеер отправляет метрику «пользователь нажал паузу на 23-й минуте», Netflix использует семантику At-Most-Once. Если консьюмер упадет и пара тысяч таких кликов потеряется — алгоритм рекомендаций этого даже не заметит. Зато система не тратит ресурсы на коммиты оффсетов и проверку дубликатов.

3. Stripe и LinkedIn: Где без Exactly-Once не обойтись
Там, где дедупликация на стороне БД невозможна (например, когда одно событие должно атомарно обновить балансы в трех разных микросервисах), включают встроенный Exactly-Once от Kafka. LinkedIn активно использует его в цепочках Kafka-to-Kafka (через Kafka Streams), чтобы при трансформации логов метрики не разъезжались ни на один цент.

💡 Интересные факты про Exactly-Once, о которых молчат в учебниках
Exactly-Once — это маркетинг (технически). Kafka не умеет маскировать сбои физики. На самом деле EOS в Kafka — это At-Least-Once доставка + автоматическая дедупликация на стороне брокера (через Sequence Numbers в памяти) + двухфазный коммит (2PC) через встроенный Transaction Coordinator.

Цена за идеальность — Latency. Включая isolation.level=read_committed, вы сознательно замедляете систему. Консьюмеры не увидят сообщения в топике, пока продюсер не закроет транзакцию. Если у вас длинные транзакции, задержка в доставке сообщений может вырасти со считанных миллисекунд до секунд.

Кафка не спасет внешнюю БД. Если ваш консьюмер принимает сообщение в режиме Exactly-Once, но внутри вашего кода пишет данные в стороннюю MongoDB или шлет HTTP-запрос в сторонний банк — транзакция Kafka никак не защитит внешнюю систему от дубликатов при сбое. Внешний мир всё равно придется делать идемпотентным вручную.

Резюме: Не усложняйте систему транзакциями Kafka там, где можно обойтись простым уникальным ключом. Встроенный Exactly-Once идеален для потоковой аналитики внутри самой Kafka, но для классического бэкенда старый добрый At-Least-Once с ручной дедупликацией - всё еще король.
Если вы применяли Exactly Once на работе поделитесь зачем и для чего?

Вот что случается когда рынок работодателя, людей массово загоняют в офисы

В этой карусели я разобрал дизайн Distributed Message Queue (распределенной очереди сообщений), сфокусировавшись на архитектурных решениях, которые позволяют обрабатывать миллиарды событий в сутки.
Что внутри:
✅ Разделение на партиции: Как масштабировать систему горизонтально и не потерять порядок сообщений.
✅ Модель PULL vs PUSH: Почему гиганты выбирают Pull для управления нагрузкой (backpressure).
✅ Гарантии доставки: Честный разговор о трейд-оффах между скоростью и надежностью (At-least-once vs Exactly-once).
🔥 Техническая «фишка» поста: Zero-copy Многие считают, что высокоуровневые языки вроде Python слишком медленны для таких задач. Но это миф. Используя системный вызов sendfile (в Python это os.sendfile), мы можем передавать данные напрямую из Page Cache в сетевой сокет.
В этом случае Python выступает лишь «дирижером» для ядра ОС. Данные вообще не копируются в память процесса и не трогают GIL, что позволяет выжимать максимум из пропускной способности сети даже на скриптовых языках.

Harness engineering
https://www.youtube.com/watch?v=rmvDxxNubIg
ключевые идеи для себя
Research -> plan -> implement
Детальная дока не имеет смысла так как оно может устареть, этап ресерча заменяет доку
План надо ревьюить обязательно, oursource thinking is bad
Имплементировать при хорошем плане может даже тупая модель
Каждый этап в отдельном чате, если контекст заполняется, начинать новый чат обязательно

А вы на каком уровне используете ии? Классно послушать набитые шишки, опыт и лайфхаки

Alex xu system design Volume 2
Если хотите на middle+, senior позиции то эта книга даст вам более углубленные знания и больше разборов разных систем

Alex xu system design Volume 1
по отзывам: если готовитесь к интервью начинайте с этой книги, она специально для этого

Мое мнение:
Back of envelope estimation нужно делать только когда это повлияет на вашу систему. К примеру хотите понять нужен ли шардинг и репликация, посчитайте qps/tps (можно и рпс, будет грубо но не зря оно back of envelope называется)
Насчет железа: стоит спросить нужно ли считать

Гоу дизайнить ютуб!
Пишу пост с жестко сухими глазами пролетая Афганистан.
Требования функциональные:
Юзер может смотреть и загружать видео
Нефункциональные:
1млн загрузок в день
100млн просмотров в день
Доступность > согласованности
Latency < 500ms
Max video size = 256gb

High level design:
User > video service > video metadata db > blob db
Начертим табличку:
Video metadata:
id, blob_path
Deep dive:
Первая проблема трафик слишком огромный желательно его не пропускать через себя если возможно, можно ходить в blob(s3) и просить pre-signed urls чтобы клиент напрямую загружал.

Загружать 256 гб целиком тяжело, сеть не надежна. Но s3 поддерживает multipart upload (загрузка кусками, обычно до 10мб кусок). В случае ошибки ретраим только посследний кусок.

Если видео весит 256 гб за 500мс мы его не отдадим, если не разрежем. После загрузки в s3 notificator посылает ивент в Chunker service и режет его на видео длинной 2-10сек. Тогда загрузка будет происходить быстро так как надо загрузить на клиент всего 2секунды видео.

Так как для нас главное доступность нам надо подумать что делать если у юзера плохой интернет. Обычно ютуб в таком кейсе понижает resolution. Отсюда следует что нам надо хранить видео не только в оригинальном resolution&bitrate.
Для этого создаем transcoder service который после слайсинга чанков будет транскодить в разные резолюшоны наши чанки.

Итогово хранить будем в метадате manifest:
{
240p: chunk1, chunk2 …
1080p: chunk1, chunk2 …
}
Так как юзеры могут быть в разных материков нужен кэш и CDN. Манифест тоже можно вынести в s3 и в cdn.

Большая часть этих вещей уже реализована протоколами HLS/DASH
Но я полагаю что главное показать что вы знаете как это фундаментально работает, а не просто сказать такой протокол + s3 прикрутим и все заработает

Масштабирование:
Все сервисы у нас stateless, там все просто. Метадата бд можно пореплицировать, надобности в шардинге при такой нагрузке нет. Если попросят то можно зашардировать на video id.
Будут мультишардовые запросы но от них никуда не дется так как будут запросы «все видео этого юзера» и «все видео с тегом Х» и тд, то есть лучше ключа нет.

Итого:
Все требования выполнены, по запросу интервьюера вы можете углубится в другие части (ретраи, балансировка, api-gw, шардинг, транскодинг)

Я считаю на систем дизайн собеседовании лучше не уточнять название бд до того как вы определились с типом нагрузки.
Выбор БД по названию — это архитектурная лотерея. Разница между B-Tree и LSM-Tree — это разница между библиотекой и блокнотом.
B-Trees (PostgreSQL, MySQL, Oracle) — это золотой стандарт для чтения. Они хранят данные в отсортированных блоках фиксированного размера.
Чтобы записать одну строку в B-Tree, диск делает 3–4 прыжка (Random I/O) для обновления индексов. На Highload это превращается в «бутылочное горлышко».
LSM-Trees (Cassandra, ScyllaDB, ClickHouse, RocksDB) — это «чит-код» для записи. Вместо того чтобы искать место на диске, они просто пишут в конец файла (Append-only).
Цифры:
• Random Write (B-Tree): ~100–500 операций в секунду на HDD, до 10k–100k на SSD.
• Sequential Write (LSM): Скорость ограничена только пропускной способностью шины (сотни МБ/с или даже ГБ/с).

Регулярно получаю предложения от топовых HFT компании на должность сеньор C++ разработчика, если кому интересно пишите я буду вас рекомендовать туда
Год назад даже в Meta звали на должность С++ developer

Кажется я научился готовить Linkedin

⚡️ Хватит стучаться в закрытую дверь: Рефералы в LinkedIn
Давайте честно: отправлять резюме через кнопку «Apply» — это лотерея, где против вас играют тысячи людей и алгоритмы ATS.

Статистика беспощадна:
Без реферала: Шанс, что ваше резюме вообще откроет человек — около 2%.
С рефералом: Шанс на получение интервью вырастает до 30-40%.

В крупных компаниях (Google, Meta, Revolut) рефералы — это основной источник найма. Сотруднику выгодно вас рекомендовать (он получает бонус), а вам выгодно попасть сразу на стол к нанимающему менеджеру.
Заходите на страницу компании и подаете заявки на connect сотрудникам и тем кто примет пишите сообщение.
📥 Как просить реферал правильно?
Главная ошибка - писать «порекомендуй меня» и ждать, что человек сам всё найдет. Чтобы получить реферал, вы должны прислать всё в одном сообщении, чтобы сотруднику осталось только нажать «Copy-Paste».

Ваш идеальный шаблон сообщения (на примере IT):

«Салем, [Имя]! Вижу, что в [Компания] открыта вакансия [Название вакансии + ID]. Я как раз специализируюсь на этом стеке. Буду очень благодарен за реферал!
Чтобы тебе было проще, вот всё необходимое:
Ссылка на вакансию: [URL]
Мое резюме: [Ссылка на Google Drive/PDF]
Короткий Pitch для рекрутера: [Ваше имя] — Senior Python Dev с 6 годами опыта, запускал системы с нагрузкой 50k RPS, отлично подходит под требования команды [Название команды]»

🛠 Почему это работает?
ID вакансии: Сотрудник не будет искать «ту самую позицию» среди 500 похожих.
Готовый Pitch: Рекрутеры просят сотрудника написать пару слов о кандидате. Напишите их за него!
Прямая выгода: Вы экономите человеку 15 минут времени, помогая ему потенциально получить бонус за найм.
Если кто хотел переехать на Кипр можете написать мне для реферала
Кстати, как вы считаете: просить реферал у незнакомого человека в LinkedIn - это норм или кринж?

📍 Как работает лента Instagram или Twitter? Разбираем News Feed System Design
Многие думают, что лента — это просто список постов от друзей в хронологическом порядке. Нажал «обновить» — полетел запрос в БД. Но если у тебя 5000 подписок, а у каждого из них миллионы фанатов, обычный SELECT положит систему за доли секунды.
Разбираем, как доставить контент пользователю мгновенно, используя архитектурные паттерны из книг Мартина К./Алекса Ксю и практики BigTech.

🛠 3 стратегии доставки контента (Fan-out):
1. Push Model (Fan-out on Write) Когда вы выкладываете пост, система тут же «разносит» его по пре-сгенерированным лентам (кэшам) всех ваших подписчиков.
• Плюс: Чтение происходит мгновенно. Пользователь просто забирает уже готовую ленту из кэша (Redis).
• Минус: Проблема «Селебрити». Если на Криштиану Роналду подписано 600 млн человек, один его пост вызовет лавину из 600 млн записей в разные кэши. Система просто захлебнется.

2. Pull Model (Fan-out on Load)
Лента собирается только в тот момент, когда вы ее открываете. Система идет в БД, ищет всех ваших друзей, достает их последние посты и сортирует.
• Плюс: Экономит место в памяти. Нет проблем с «тяжелыми» пользователями.
• Минус: «Тяжелое» чтение. Если вы подписаны на 1000 человек, ваш запрос будет медленным и создаст огромную нагрузку на базу данных.

3. Hybrid Model (Золотая середина)
Сочетаем оба подхода.
• Для обычных пользователей используем Push. Их посты сразу летят в ленты друзей.
• Для звезд (Celebrities) используем Pull. Их посты не рассылаются заранее. Когда вы открываете ленту, система отдельно докачивает посты «звезд» и подмешивает их к вашему основному кэшу.
• Так работает Twitter: они используют статус «In-memory Graph», чтобы понимать, кто на кого подписан, и динамически собирать ленту.

🚀 Что происходит «под капотом» (Feed Ranking):
Просто показать посты по времени — скучно. Современная лента — это Ranking Service.
1. Фильтрация: Убираем дубли, рекламу и посты, которые вы уже видели.
2. Scoring: ML-модель считает вероятность вашего лайка. Учитывается всё: как долго вы смотрели на фото, писали ли коммент автору раньше, тип контента (видео/фото).
3. Сборка: В кэш (обычно LRU Cache) подгружается только «голова» ленты (топ-20 постов). Остальное догружается лениво (Lazy Loading) по мере скролла.

Где почитать/потренить:
По этой теме есть классическая задача на System Design интервью. Разбор базовых компонентов можно найти в материалах ByteByteGo или классике: «Designing Data-Intensive Applications» Мартина Клеппмана.