Всем привет. Нарушаю тишину в эфире.

На прошлой неделе я рассказывал, как проходил разные этапы собесов, в том числе и про этап системного дизайна. В комментариях попросили подробнее рассказать про один из кейсов, что я с радостью и сделаю.

Но также в комментариях я встречал, что не все в курсе, что это за секция и как её проходят.

Чтобы выровняться по ожиданиям и бэкграунду, я решил сперва написать, как я обычно прохожу эту секцию. Усаживаемся по удобнее, записываем 🗒

Для начала, не стоит волноваться лишний раз

Если вам предложили пройти эту секцию, можно радоваться, значит вас рассматривают на синёра или выше.

Начну с того, для чего вообще нужна эта секция. Тут не как с алгоритмами, которые должны работать за определённую сложность.

Решение по резульатам секции может быть и не особо рабочим в реальности — никто проверять не будет. Тут проверяется, насколько вы хорошо умеете собирать требования к задаче, искать сложности, понимать ограничения предложенных решений и вообще насколько большой у вас кругозор. То есть, за достаточно короткий срок, можно собрать максимум информации о кандидате.

Задачи на этом этапе могут быть самые разные: от "спроектируй твиттер с 1М RPS" 😎 до "распределённый сокращатель ссылок" или реально существующей системы внутри компании. При этом само интервью длится всего час, и все понимают, что за час рабочее решение не спроектировать. Но ожидается, что соискатель:

*️⃣ соберёт функциональные и нефункциональные требования;
*️⃣спроектирует примерный API;
*️⃣спроектирует примерную структуру хранилища;
*️⃣посчитает нагрузку — RPS, размер хранилища, память. Можно упороться и просчитать ещё CPU, сколько нужно серверов;
*️⃣конечно, спроектирует happy path — успешный сценарий работы;
*️⃣опишет пограничные состояния;
*️⃣расскажет, как будет масштабироваться;
*️⃣будет использовать обоснованные реальные инструменты.

Выглядит как слишком много для одного часа, поэтому для прохождения этапа важно действовать чётко и по таймингу, чтобы залутать как можно больше очков в глазах собеседующего. Относиться к этому можно как к квесту в вашей любимой игре 🤬

Примерный тайминг следующий:

*️⃣Сбор требований — 5 минут. На этом этапе важно записывать все требования. В процессе вы ещё не раз к ним вернётесь — это раз. А второе — когда нужно будет проверить соответствие системы требованиям, будет куда смотреть.
*️⃣Примерная оценка нагрузки — 5 минут. Можно подготовить формулы заранее. Тут небольшой лайфхак — структуру базы для расчёта размера хранилища, скорее всего, не выйдет сделать до получения хотя бы абстрактной архитектуры. Поэтому, чтобы не переделывать структуру и не пересчитывать потом по новой, можно перенести этот этап и сделать после проектирования happy path сценария.
*️⃣Проектирование API — 5 минут. Не нужно тут прям всё по REST’у делать. Можно сделать «псевдо-эндпоинты».
*️⃣Проектирование абстрактной архитектуры — до 30 минут. Тут нужно привести реально существующие инструменты и быть готовым защитить, почему именно Kafka, а не Rabbit, например. Не нужно уходить в дебри технологий, если задача этого не требует. Не нужно лепить избыточные узлы, если об этом не просят. Думаешь добавить geo DNS? А сервис точно гео-распределённый?
*️⃣Обсудить, как система противостоит сбоям и как масштабируется — 5 минут.

Что ещё проверяется?

*️⃣Что соискатель может отстоять своё решение.
*️⃣Сосикатель умеет выражать свою идею.
*️⃣Соискатель понимает как проектируются системы

Как видно, тайминги сжаты, и перед реальным интервью нужно потренироваться — пройти mock-интервью с ментором или попросить ChatGPT погонять по секции.

Важный нюанс — даже если система спроектирована чётко, все расчёты сделаны, вопросы закрыты, есть фактор субъективности интервьюера. И даже при идеальном прохождении можно получить отказ.

Как вы относитесь к данной секции?

⸻

Давайте оставаться на связи ☄️

Ты тимлид в новой команде. Что делать?

Привет! Продолжаю тимлидские разгоны.

Последние 3 недели я погружаюсь в новый продукт и новую команду. По этому вспомнил сам и решил рассказать вам как же правильно входить в новую команду.

На самом деле тут много нюансов и разных тонкостей, на которые стоит обратить внимание, но базовый алгоритм такой

✅ Тебя должны представить команде. Сделать это должен или прошлый руководитель, если он в ладах с командой, или твой собственный лид. Ты человек новый для команды, таким нехитрым приёмом предыдущий лид или твой лид делится с тобой своим авторитетом перед командой. Тут работает когнитивное искажение "эффект ореола".

✅ Проведи оценку своего нового подразделения. Из каких частей ссстоит, познакомься с орг. структурой, какие есть вакансии, какой отток, какие причины, в каком состоянии члены команды. Тут может помочь HRBP, если он есть, или предыдущий лид, если он был.

✅ Нужно встретится с каждый членом твоей новой команды. Нужно будет выяснить чем они сейчас занимаются, какое состояние текущих задач и целей. И, конечно, назначить регулярные 1-1.

✅ Дальше разберись в процессах и вообще чем занимаются твои сотрудники. Может быть дежурства есть, какие-то ежедневные активности, которые не отражены на доске.

✅ Если есть управление бюджетом тоже твоя ответственность, то нужно выяснить какие статусы по зарплатам, премиям, отпускам. Кому давно не повышали зарплату, может кто-то выпал из вилки.

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

Может я что-то упустил? Тогда напиши об этом в комментариях.

⸻

Давайте оставаться на связи ☄️

Разбор задачи system design - передача местоположения курьеров.

Привет! В комментариях к посту с историями про собесы была просьба разобрать задачу. Выполняю)

Я попробовал восстановить так, как это было на самом собесе, ничего не добавляя постафктум. Решение может отличается от того, как сделали бы вы, это нормально.

Задача была поставлена следующим образом (с учётом собранных мною требований):

Представьте, что вы проектируете бэкенд для клиентского приложения доставки. Пользователь открывает экран заказа и хочет увидеть, где сейчас находится его курьер.

На вход у нас есть два внешних API, на которые мы не можем повлиять:

1. Order API — по order_id возвращает данные по заказу, в т.ч. и courier_id. Среднее время ответа — 1 секунда.
2. Courier API — по courier_id возвращает текущие координаты. Среднее время ответа — ещё 1 секунда.

Наш сервис должен принимать запрос от клиентского приложения вида

GET /orders/{order_id}/location

и отвечать координатами курьера: широта и долгота.

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

Дополнительные условия:
- Мы не знаем список заказов заранее — о заказе узнаём, когда клиент впервые запрашивает его позицию.
- Внешние API трогать или ускорять нельзя.
- Сервис должен быть масштабируемым, отказоустойчивым и геораспределённым. 🐱

То есть нам нужно уложиться в SLA 0.3 секунды, хотя единственное место, где есть нужные данные, отвечает ~2 секунды. 😨

Как это сделать? Чистая архитектура, никаких костылей.

Чтобы уложиться в SLA по времени отклика и при этом не зависеть от скорости внешних API, система строится вокруг нескольких ключевых принципов:

1️⃣ Асинхронное наполнение данных (warm-up).
Первый запрос по заказу не вызывает цепочку из двух медленных API. Вместо этого сервис мгновенно возвращает location = null, а фоновый воркер начинает процесс получения данных:
*️⃣обращается к Order API, чтобы получить courier_id;
*️⃣по этому courier_id запрашивает координаты в Courier API;
*️⃣сохраняет результат в Cassandra.
После этого все последующие запросы по данному заказу читают данные напрямую из базы.

2️⃣ Хранение в Cassandra без промежуточных кэшей.
Сервис не использует локальные in-memory или Redis-кэши. Все данные хранятся централизованно в Apache Cassandra, которая обеспечивает:
*️⃣быструю запись (до десятков тысяч upsert-ов в секунду на ноду),
*️⃣горизонтальное масштабирование без единой точки отказа,
*️⃣репликацию между регионами.
Используется стратегия NetworkTopologyStrategy с ReplicationFactor = 3 на каждый регион и уровень согласованности LOCAL_QUORUM — это позволяет читать и писать данные локально, не дожидаясь удалённых DC.

Почему Cassandra, а не Redis?

Получился лонгрид, не поместилось в один пост, продолжаю тут — https://teletype.in/@mifleo/system-design-courier-location

В комментариях предлагаю обсудить:
*️⃣что бы вы сделали иначе?
*️⃣какую задачу еще разобрать?

⸻

Давайте оставаться на связи ☄️

Всем привет!

Сегодня хочу поделиться с вами записью моего выступленя с пых.конф про мьютексы и другие примитивы.
Приятного просмотра. Буду рад обратной связи)

https://www.youtube.com/watch?v=dyy8KLoq2oY

⸻

Давайте оставаться на связи ☄️

Собрал полный зал на higload 🤩

Всем привет!
Мой сезон конференций 2025 завершён. За год удалось выступить на десятке конференций и митапов, среди которых:

- DUMP Spb - про то, как собирать и отправлять прдуктовые метрики без потерь
- PodlodkaCrew PHP - когда индексы не работают
- пых.конф'25 - мьютексы и другие примитивы
- пыхап x lamoda.tech - observability в php без боли
- Higload++
- и т.д.

Ещё провёл больше сотни часов вебинаров на разные темы, связанные с архитектурой и СУБД, а также элективный курс по System Design для Иннополиса.
Плюс — дважды собирал потоки с темами про PHP-разработку на конференции "Стачка" (весной — в Ульяновске, осенью — в Питере).

Завершает сезон конференций, традиционно, Highload++.
Я выступал в последний слот перед закрытием конференции — не в главном зале, но во втором по вместимости.
Зал был полным: судя по статистике, мой доклад пришли послушать около 120 человек офлайн.
30 минут длилось выступление и ещё 30 — ответы на вопросы после.

Правда, доклад мог и не состояться: ещё накануне конференции я почувствовал першение в горле, а к дню выступления горло уже болело во всю. На сцену вышел с температурой около 38 🌡

Но в итоге я доволен тем, как всё прошло. Несмотря ни на что, старался держаться и дорабатывал презентацию почти до самого доклада — хотел сделать её лучше и нагляднее.
Оценки получились высокими, комментарии — развёрнутыми и очень тёплыми.
Всем спасибо, кто пришёл!


Сама конференция, как всегда, прошла бодро: много новых знакомств, старых друзей и отличные доклады на любой вкус.

Были ли вы на Хайлоаде в этом году? Как вам?

⸻

Давайте оставаться на связи ☄️

Всем привет!

У себя в блоге, да и в целом в других источниках, чаще всего я встречаю информацию об архитектурных шаблонах высшего порядка. К таким относятся монолитная архитектура разных видов, микросервисная, n-tiered, plug-in и прочее. Намного реже можно встретить шаблоны низшего порядка, такие как retry pattern, circuit breaker, throttling и прочие. Обходить их стороной нельзя, потому что без них не обходятся большие системы.

Шаблоны низшего порядка можно разделить на 7 видов:
*️⃣ Шаблоны обеспечения надёжности
*️⃣ Шаблоны обеспечения безопасности
*️⃣ Шаблоны переиспользования
*️⃣ Шаблоны эволюционности и интегрируемости
*️⃣ Шаблоны развёртываемости
*️⃣ Шаблоны тестируемости
*️⃣ Шаблоны согласованности чтения и записи

Решил сделать цикл заметок на тему шаблонов низшего порядка. Какие-то из них очень популярны и в дополнительных обсуждениях не нуждаются, а какие-то встретишь нечасто, но от этого они не становятся менее эффективными.

Цикл начну с одного из паттернов надёжности — Queue-Based Load Leveling Pattern.

В своей работе я часто сталкивался с ситуациями, когда система подвергалась нагрузкам волнообразно. Например, это мог быть импорт товаров для обновления остатков на складе или массовая загрузка сущностей в систему. В такие моменты нагрузка на критические части возрастала, и продукт мог отказывать в обработке клиентских запросов.

Паттерн, о котором я говорю, призван решать такие проблемы. Мы создаём очередь между отправителем и получателем, которая работает как буфер и хранит сообщение, пока мы не сможем его обработать. Получатель обрабатывает в своём темпе, и это не приводит к резким всплескам.

Применять этот подход можно не только к массовым обращениям, но и к долгим. Например, система должна отреагировать на некоторое событие и выполнить запрос в 3rd-party приложение. Такую команду также можно положить в буфер и обработать асинхронно.

Применяли ли вы этот паттерн? Какой ещё раскрыть подробнее?

⸻

Давайте оставаться на связи ☄️

Всем привет! Начинаем утро с архитектурных паттернов 😎

Итак, в прошлом посте я рассказал про один из шаблонов обеспечения надёжности. Какие вообще шаблоны входят в эту категорию? А вот они все:

*️⃣Retry pattern
*️⃣Circuit Breaker
*️⃣Throttling
*️⃣Bulkhead
*️⃣Rate Limiting
*️⃣Fallback Cache
*️⃣Null Object
*️⃣Priority Queue
*️⃣Leader Election
*️⃣Queue-based Load Leveling
*️⃣Health Endpoint Monitoring

Я не буду подробно останавливаться на каждом, потому что многие из них настолько популярны, что в дополнительном представлении не нуждаются.

Но о некоторых я бы поговорил детальнее.

К вашему вниманию Bulkhead Pattern.

Когда мы говорим о распределённых или облачных приложениях, то у них, как правило, много потребителей. Если на наш сервис подаётся избыточная нагрузка, это приведёт к тому, что все потребители будут страдать.

Суть паттерна
Разделяем ресурсы и компоненты на независимые «отсеки» (bulkheads).
Если один сервис, поток или клиент ложится — остальные продолжают работать.
Это как перегородки в корабле: пробило одну — остальные держат корабль на плаву.
Например, у нашего приложения есть 3 внешних сервиса: A, B, C.
Если сервис A подвиснет и «съест» весь connection pool, без bulkheads клиент потеряет возможность ходить и в B и в C — полный шатдаун.

Но если у каждого сервиса свой connection pool, то:
*️⃣A завис → пострадал только его пул
*️⃣B и C работают стабильно

Bulkhead отлично подходит, когда нужно:
*️⃣изолировать критичные функциональные части от менее важных
*️⃣защититься от каскадных отказов
*️⃣сохранить частичную работоспособность даже если часть системы упала

Использовали такой?

⸻

Давайте оставаться на связи ☄️

Привет!
Вдруг вы пропустили, недавно Онтико (организаторы хайлоад, тимлид конф и прочего) выкатили результаты опроса сообщества на тему «что не так с конфами» (помимо стоимости билета под 100к).

Там всё прекрасно, и всё мне откликается. И усталось от лекций (пересказов доки), и сфокусированность на бигтехах (будто кроме них ничего больше нет). Вообще, способ шаринга знаний сильно изменился за последнее время и ИИ этому сильно поспособствовал.

Не удивительно, что голая теория сейчас уже не заходит. Интересен опыт и способы внедрения, дискуссия вокруг какой-то темы.

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

Мне ближе формат таких заметок, как я сам веду. Я стараюсь концентрировать свои наблюдения и опыт, которые можно уместить в один пост Телеграмм. А для специфичных запросов обращаюсь за менторской помощью к более опытным коллегам. Такие дела.

Что вы думаете про современне форматы конференций? Как теперь получать знания? 🙂

⸻

Давайте оставаться на связи ☄️

Всем привет!

Продолжая тему шаблонов низшего порядка, хотел бы обсудить категория паттернов масштабируемости. Многие из них настолько популярны, что мы их применяем даже не задумываясь.

В эту категорию попадают:

*️⃣ Load Balancer Pattern
*️⃣ Cache Pattern
🔤Cache-aside
🔤Write-throught
🔤Write-behind
🔤Refresh-ahead
*️⃣Materialized View
*️⃣Index Table Pattern
*️⃣CQRS
*️⃣Computing Consumer
*️⃣Sequential Convoy
*️⃣Federation Pattern
*️⃣Sharding Pattern
*️⃣Static Content Hosting Pattern

Про то для чего нужен Load Balancer все и так знают. Он работает как единая точка входа и распределяет нагрузку между инстансами сервиса. Применяя простые и не очень алгоритмы балансировки, это может помочь сделать нагрузку равномерной. Тут и всякие random, и round robin и weight round robin, и т.д.

Про кеш и его стратегии можно говорить очень долго и много. Кстати, стоит об этом рассказывать? Потому что у меня много накопилось опыта организации кеша.

Очень редко слышу про Sequential Convoy pattern, а между тем, в распределённых системах это очень важная штука.

В распределённых системах часто нужно обрабатывать сообщения строго по порядку, но при этом не терять возможность горизонтального масштабирования. Типичный пример — операции над заказами: создать, добавить транзакцию, изменить, удалить. Важно, чтобы все шаги для конкретного заказа шли FIFO. Но в очереди перемешаны события от тысяч заказов.

В обычном Competing Consumers воркеры читают сообщения параллельно. Это круто для пропускной способности, но:

*️⃣порядок обработки гарантировать невозможно
*️⃣операции для одного объекта (например, orderId=123) могут попасть разным воркерам
*️⃣появляется риск гонок, конфликтов и «разъехавшегося» состояния

Sequential Convoy pattern элегантно решает эту проблему.

Разделить сообщения по категориям, где категория = единица сериализации и масштабирования.

Например:
*️⃣категория = OrderID
*️⃣категория = CustomerID
*️⃣категория = SessionID
*️⃣категория = DeviceID

Каждая категория обрабатывается строго последовательно, но разные категории — параллельно и независимо.

То есть мы жёстко сериализуем только то, что должно быть сериализовано, и масштабируемся по количеству категорий.

Как работает паттерн

1️⃣Есть входная очередь, куда прилетают перемешанные сообщения.
2️⃣Фоновый процесс (ledger processor) разбирает сообщения и отправляет их во вторичную очередь, выставляя sessionId = categoryId (например, OrderID).
3️⃣Консьюмеры читают эту очередь по сессиям:
*️⃣один воркер → одна категория → FIFO
*️⃣как только воркер закончил категорию, он может взять следующую

Таким образом:
*️⃣порядок внутри категории сохраняется
*️⃣масштабирование идёт по количеству категорий

Когда не подходит:
*️⃣экстремальные нагрузки: миллионы сообщений в секунду — FIFO-сериализация будет узким местом
*️⃣нет чёткого ключа категории
*️⃣порядок не критичен

Такой подход снимает гонки и конфликты, даёт чёткую единицу масштабирования, повышает нажёдность цепочек обработки. Но вместе с тем, требует брокера с поддержкой сессий, маленькое количество категорий = маленький масштаб.

Сам паттерн не указывает как обеспечить порядок внутри очереди, это остаётся на уровне инфраструктуры. Паттерн помогает масштабировать и не терять упорядоченность.

Применяли ли вы такое или что-то подобное в своей работе?

⸻

Давайте оставаться на связи ☄️

Всем привет.
Слушаю я сейчас «Государя» Макиавелли, и там проскочила цитатка: «Люди судят не по замыслам, а по действиям. И по тем действиям, которые видны».

Я подумал, что есть всё-таки вечные паттерны, зашитые в нас с самых древних времён.

Сегодня, в контексте моей непостоянной рубрики #soft_friday, я бы хотел поразгонять на нетехническую тему и обсудить такую штуку, как «видимость» и как она влияет на карьеру.

Видимость — это то, насколько другие люди понимают:

*️⃣какую ценность ты создаёшь;
*️⃣на каком уровне сложности ты работаешь;
*️⃣как ты влияешь на продукт, команду и риски;
*️⃣можно ли на тебя опираться в сложных ситуациях.

То есть видимость — это сигнал, который получают коллеги о твоей реальной пользе.

Не стоит путать это с тем, чтобы быть в каждом чате самым умным и мелькать в каждом треде. Это — умение сделать так, чтобы твоя ценность не была скрытым знанием внутри маленькой рабочей группы.

Иногда видимость может влиять на карьеру больше, чем компетенции.

Почему так? Потому что многие решения о росте принимают люди, которые не видят твоей работы напрямую. Они не сидят с тобой на дейлике, не видят, как ты разгрёб сложный инцидент или затащил большую фичу. Для них ты — абстрактный объект, про который приходят сигналы.
А если сигналов нет — ты невидим. Если сигналы есть — ты становишься заметным и понятным.

Как формируется здоровая видимость?

Точно не за счёт того, чтобы быть «в каждой бочке затычкой».

Нужно показывать работу, её сложность и влияние.
Не «я сделал Х», а:
«Было вот так, влияло на это, сделал вот так — и стало лучше. Вот как это измерить».

Показать, как ты влияешь не только внутри своей зоны ответственности, но и за её пределами.
Показывать прозрачные и предсказуемые результаты.

Видимость напрямую связана с репутацией, и она может быть токсичной. Если по какой-то причине наружу просачивается информация о неудачах больше или раньше, чем об успехах — это может надолго закрепить славу «того самого, кто отрефачил систему и положил прод».

Как посылать эти самые сигналы?
*️⃣Написать пост в рабочем канале о том, какую классную штуку ты сделал.
*️⃣Сделать доклад и выступить на локальном митапе.
*️⃣Если есть 1:1 с руководителем руководителя — рассказать там. Если такой встречи нет, её можно назначить и обсудить результаты и влияние.

В общем, видимость — это мощный инструмент в вашей карьере. Но им нужно пользоваться аккуратно и с умом, иначе он может выстрелить против вас.

Получается ли у вас работать со своей видимостью?

⸻

Давайте оставаться на связи ☄️

Всем привет!

Этот пост будет посвящён монетизации моих знаний и умений.

🔤🔤🔤
Дисклеймор:
Я знаю, что многим не нравятся такие посты в каналах и может возникнуть желание отписаться. Я призываю не делать этого, весь контент в моём канале был, есть и будет бесплатным и максимально полезным. А выпускать я будут с такой же нерегулярностью как и всегда.
🔤🔤🔤

Для начала, для всех, кто присоединился недавно или кто меня совсем не знает, расскажу пару слов о себе.

Меня зовут Олег, сейчас я руководитель команды разработки в Т-банке. Больше 15 лет разрабатываю и проектирую сложные системы. Пишу, в основном, бекенды, работаю с реляционными СУБД, observability, system design.
Знаю как строить карьеру. Я работал в Вконтакте, Skyeng и других крупных компаниях продуктовой и заказной разработки.
Строил команды и процессы с нуля, улучшал старые, внедрял новые. Растил крутых разработчиков и лидов.
Выступаю на крупных и не очень конференциях. В моём канале можно найти видео с докладов.
Много лет преподаю и делюсь знаниями как на сессиях один-на-один, так и на групповых занятиях.
Провёл больше сотни интервью как собеседующий и сам успешно проходил собесы в компании десятки раз.

Итак, чем я могу вам помочь:
*️⃣нужна помощь в подготовке к интервью по программированию. Мы можем провести mock-итервью, по итогу я дам рекомендации по подготовке.
*️⃣нужна помощь в system design интервью. Тут схема такая же, как выше.
*️⃣хочешь расти в техлида, но не знаете как. Мы сможем созвониться, понять текущий уровень и построить дорожную карту.
*️⃣хочешь расти в тимлида. Тут аналогично предыдущему пункту.
*️⃣хочешь расти, но не знаешь как. Всё ещё то же самое.
*️⃣запрогал какой-то проект, но не знаешь хорошо ли. Мы созвонимся, проведём код ревью и обсудим что можно улучшить.
*️⃣нужно спроектировать какой-то сервис, но не знаешь как подступиться или не понятно взлетит ли. Созвонимся, посмотрим, порисуем.
*️⃣помочь в подготовке доклада на конфу и потренироваться перед выступлением.
*️⃣и многое другое, что можно обсудить индивидуально.

Пишите! Связаться со мной можно тут в сообщениях в канале или сразу в личку — @mifleo. Обсудим детали.

Забукать слот можно тут https://planerka.app/oleg-mifle/mentor-60min

Всех обнял.❤️

Доброе утро пятницы 🤩

После одной из лекций мне задали хороший вопрос.
Я объяснял разницу между B-tree и B+tree и упомянул, что в B+tree ключи дублируются: они присутствуют в листьях и во внутренних узлах.
Из этого следует важный вывод:

В чистой теории B+tree не компактнее B-tree — он действительно хранит больше ключей.

Тогда где же профит?
Почему все современные СУБД используют именно B+tree-подобные индексы?
Разбираемся спокойно и последовательно.

1️⃣ Теоретическая база: B-tree vs B+tree

Что такое классический B-tree
*️⃣Ключи и значения могут храниться как в листьях, так и во внутренних узлах.
*️⃣Каждая запись хранится ровно один раз.
*️⃣Внутренний узел содержит полноценную запись: key + value + pointer.

➖Вывод: внутренний узел "толстый" → мало элементов → низкий branching factor → дерево выше.


Что такое классический B+tree
*️⃣Полные данные хранятся только в листьях.
*️⃣Внутренние узлы содержат только ключи и указатели.
*️⃣Ключи действительно дублируются:
*️⃣в листьях — как реальные данные,
*️⃣во внутренних узлах — как границы диапазонов.

➖ Вывод: формально количество ключей в B+tree больше, чем в B-tree.

2️⃣Почему B+tree всё равно ниже

Ключевая вещь: важен не счёт ключей, а размер записи во внутреннем узле.
*️⃣В B-tree внутренняя запись = key + value.
*️⃣В B+tree внутренняя запись = key (и pointer).

То есть непросто больше места — разы больше элементов на узел.

➖ Внутренний узел B+tree вмещает радикально больше ключей, чем B-tree.
➖ Branching factor выше.
➖ Дерево ниже, поэтому меньше переходов между страницами.

А каждый уровень дерева — это потенциальный I/O. Чем их меньше, тем быстрее индекс.

3️⃣Теперь к практике: индексы PostgreSQL / MySQL / SQLite

В реальных СУБД всё завязано на страничную архитектуру.
И индексы там — это именно B+tree-подобные структуры, потому что так эффективнее работать с блоками фиксированного размера.

Как устроен реальный индекс:
*️⃣Внутренние страницы: только ключи + указатели на страницы.
*️⃣Листья: ключи + tuple pointer (ссылка на строку таблицы).
*️⃣Payload строк в индексе нет — он живёт в таблице.
*️⃣Листья связаны для быстрых range scan.

➖ Итог: внутренние страницы очень плотные, дерево низкое, запросы минимально трогают диск.

4️⃣Так почему же B+tree-индекс меньше, хотя ключей больше?

Ответ в инженерной экономике:
*️⃣Плотные внутренние страницы.
*️⃣Ни один внутренний узел не содержит payload.
*️⃣Высота дерева меньше → страниц меньше.
*️⃣Split-ключи, которые дублируются, маленькие и почти ничего не стоят.
*️⃣Зато payload (который хранился бы в B-tree) весит много — и именно он раздувал бы индекс.

То есть чистая теория говорит, что B+tree содержит больше ключей. Реальная СУБД показывает, что B+-индекс занимает меньше места и работает быстрее.

В теории B+tree действительно хранит больше ключей, чем B-tree. Но в реальной СУБД B+tree выигрывает по всем фронтам: меньше уровней; меньше I/O; меньше страниц; отсутствие payload во внутренних узлах; быстрые диапазонные запросы за счёт связных листьев.

Вот почему PostgreSQL, MySQL, SQLite и большинство хранилищ используют именно B+tree-подобные индексы, а не чистый B-tree.

⸻

Давайте оставаться на связи ☄️

Всё переплетено, или как связана недавняя уязвимость в React с Cloudflare.

Всем привет! Давайте обсудим как все это связано.

Что случилось в React?
React Server Components — это технология, которая позволяет выполнять часть компонентов прямо на сервере. Это удобно: можно лезть в базу данных, собирать тяжёлые данные, не утекать в клиентский бандл.
Сервер и клиент общаются через специальный бинарный протокол, где React сериализует данные, а потом десериализует их обратно.
И вот именно в этой части — в десериализации данных — и лежала уязвимость. React доверяет входящим данным слишком сильно. Если отправить на сервер специально сформированный пакет, можно было:
*️⃣подменить внутренние ссылки на модули,
*️⃣загрязнить прототипы (proto),
*️⃣выйти на цепочку constructor → constructor,
*️⃣и выполнить любой JavaScript-код на сервере.

Если у вас Next.js с App Router, то это вот оно — надо апдейтить пакет.

Так, и при чём тут падения Cloudflare?

Если вы помните, за последнее время было два глобальных падения. Первое — 18 ноября. Разборов полно в интернете, но если кратко: у Cloudflare есть система bot management, определяющая, бот ты или человек. Она работает на ML-модельке. Чтобы она работала, в модель нужно скормить файлик: его генерируют по данным из ClickHouse.

В один день ребята решили мигрировать кластер на новую модель доступа, а действующий скрипт вытаскивал данные:

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

То есть нет фильтра по базе. Это не удивительно — обычно мы работаем в контексте какой-то одной базы. Раньше из-за области видимости всё работало нормально, а потом таблица "появилась" ещё и в другой базе потому что CH начал возвращать метаданные ещё и из другой базки. В итоге файлы для модели сильно распухали из-за неожиданно лишних данных и выпадали за лимит.

Дальше прокси на FL2, написанный на Rust (запомните этот факт), пытался загрузить файл. Кривенько написанный код проверял лимит фич в файле, функция выбрасывала панику.
В интернетах потом долго набрасывали на Раст и его чрезмерную строгость и жёсткость. Хотя, как по мне, винить инструмент — затея сомнительная. Хотя и целый день поднимать один сервис тоже такое себе.

Второй инцидент — 5 декабря — уже отсылает к найденной уязвимости в React.
Чтобы защитить клиентов, Cloudflare увеличил буфер WAF до 1 МБ и поправил правила парсинга. Всё завелось, пока не отключили тестовый ruleset через глобальную конфигурацию.

После этого начал отстреливать старый код на Lua на FL1 (который ещё не перевели на Раст). Код ожидал объект, которого не было в продовом ruleset.
При этом Раст на FL2 отработал без проблем — он же строго типизирован, и такие проблемы с консистентностью не допускает.

В разборе инцидента Cloudflare явно это подсвечивают, и выглядит это так, будто они пытаются оправдать Раст после первого инцидента. Типа: «вот вы пугаете Раст за излишнюю строгость, а оно вон как». И вот думай теперь, то ли они искали повод обелить Раст, то ли реально уронили не специально.

Вообще я люблю читать постмортемы — часто это увлекательнее хорошего детектива.

А как вас задели падения Cloudflare и новая уязвимость React?

⸻

Давайте оставаться на связи ☄️

Всем привет!

Пост для тех, кто неравнодушен к PHP . Да и не только, к программированию в целом.

Недавно Валентин Удальцов (канал @phpyh, «пых.конф»), Данил Щуцкий и CutCode решили запустить интересную платформу.

По порядку. Какую проблему ребята хотят решить?
В сообществе есть много интересных людей, которые могут поделиться экспертизой, но не готовы вкладывать в это время. Их можно поддержать финансово, дать мотивацию делится знаниями, но как? Есть платформы типа Бусти или Патреона, но в них тоже надо вкладываться и продвигать себя и не факт что окупится вообще.

Родилось интересное решение. Ребята создали платформу прямо в Telegram — PhPeople, в рамках которой будет собираться PHP-сообщество, а авторы контента смогут немного заработать.

Платформа работает по механике подписок:
Первый уровень — подписка на базовую группу, в которой авторы будут делиться некоторым своим контентом.
Второй уровень — подписка на конкретного автора, где уже будет больше контента конкретной тематики.

Стоимость каждой подписки — 150 рублей в месяц. Меньше чашки кофе, но пользы от неё сильно больше. В общем, собираешь как пазл.

Сейчас там уже 5 авторов:
*️⃣Я — традиционно буду разгонять про архитектуру и прочее. Решил попробовать формат видео, и первая серия роликов будет посвящена тому, как мы рефачим реально существующий легаси-проект: делаем его из жёсткого самописа и каши из кода в проект, где всё на своих местах.
*️⃣Валентин Удальцов — будет проводить всякие закрытые стримы и поднимать темы про PHP.
*️⃣Кирилл Несмеянов — рассказывает про самую внутрянку и прочий хардкор, и computer science.
*️⃣Дима Дерепко планирует писать про разработку плагинов под IntelliJ IDEA.
*️⃣Алексей Гагарин — человек, который делает множество open source-решений, будет рассказывать про свой фреймворк-убийцу PHPUnit.

Пул авторов будет расти, а подписаться можно через бота @phpeople_bot. Ещё, в этот вторник (16.12.2025) соберемся с авторами и создателями платформы, обсудим что это и для чего это может быть нужно.

Как вам идея?