System Design World

🌶️ Кейс авито - решардинг ClickHouse.

Что могло пойти не так? А может, всё так! 🙃
Компания столкнулась с задачей роста данных. ↗️

А конкретнее:
😳 Диск заполнен на 90–95%
😳 Упёрлись в потолок сбора новых данных
😳 В пиковые моменты ClickHouse упирался в предел ОЗУ

Приходим к любимому кейсу System Design - как нам сделать качественный решардинг!
Вопрос со звёздочкой на собеседование! *

👨‍🎓 Евгений Уласик, Senior BE-инженер avito.tech, расскажет реальный продовый кейс.
Смотрим и наматываем на ус 🥸

⏰ Когда:
Среда, наша рубрика - System Design Chill, 19:00.`
Ссылка будет здесь. ✍️

😊 Провели отборочный тур!

4 финалиста найдены!🔨
Проходки начинаем делать!

Подарок от Yandex Cloud нашёл своего обладателя! 🎖

В 1ом сезоне нас было ~30 участников!
В этот раз ~50! 📈

Растём!💪

🕯 Встретимся на HighLoad++!

Будем продолжать System Design активности!

System Design Игра!

Ещё раз проговорим формат.
С разрешения собеседника.

+Специальный приз от Yandex Cloud🎁

🌴💃 2-й сезон System Design Игры! Let's play!

Они объединились:

Yandex Cloud
System Design World
HighLoad++

Чтобы провести System Design игру!
Завтра вечером старт отборочного этапа!

Успеть зарегистрироваться:
🔘Заполнить форму

За победу🏆: билет на HighLoad++ и возможность участия в финальном туре!

Подробности здесь.

ИИ вместо нас?

👨‍💻 Агрегировал своё отношение к LLM.
На uwdc перед своим докладом сходил на ИИ активности, доклады.

Итого:
1) То, что я не участвовал в хайпе последних ~4 лет, - ничего не потерял. Не пудрил себе мозги, не тратил жизненное время, не переживал.
2) Вышли прорывные версии LLM - паниковал из-за того, что

ТЫ ТЕПЕРЬ НЕ НУЖЕН!
СРОЧНО СДЕЛАЙ ЭТИ 3 ШАГА

А я не в теме.
3) Посмотрел за пару недель основные для себя видео "Как приручить Дракона", мнение экспертов
4) Выработал своё мнение
5) На конференции откалибровался: что делаю и как сейчас принято в индустрии:
а) Скиллы
б) Четкий контекст
в) Индексация благодаря memory.md
г) Сюда ходи, сюда не ходи
д) Ты - профессионал в домене, а это твой подручный

🔘Проффит

Могу смело не тратить внимание дальше на 100500 повторяющих одно и то же видео.

🔘В очередных постах поделюсь мнением, что же на самом деле представляет собой текущий ИИ.
И там не будет паники.❗️

Вас тревожит ИИ хайп?

⚡️ - интересно что же такое - современный ИИ

🐦‍🔥 System Design Интервью. Мой первый fail, уроки и успешный фреймворк прохождения

❗️ Рассказал про кейс из первых прохождений System Design Интервью в конце 2010ых в отечественный БигТех.
🟢Какие сделал выводы.
🟢Озвучил грабли.
➡️И вместе с ведущими UWDC разобрали успешный пайплайн прохождения интервью.📈

🌶️ Запись уже доступна!
Смотреть - 💙 VK

UWDC всё ближе, а митапов — всё больше. В среду, 13 мая, в 19:00 (МСК) послушаем Владимира Невзорова и узнаем больше о System Design.
-
System Design Интервью — история фейла и уроки
Владимир Невзоров
Москва, servicepipe, Senior backend
13 мая 2026, 19:00 (МСК)
-
Очень часто в рамках собеседований на позиции аналитиков, бэкендеров и даже продактов есть часть, посвящённая System Design. И, как говорят, многие её боятся) А ещё говорят, что System Design очень важен и без него прям никуда) Но почему?! Может быть это как с особым вопросом на экзамене, который добавили, чтобы было поменьше пятёрок? И нужно просто не бояться и выдать экспромт?)

Однако, лучший экспромт — это подготовленный экспромт)) И подготовиться нам поможет Владимир Невзоров. В рамках митапа «System Design Интервью – история фейла и уроки» 13 мая в 19:00 (МСК) он расскажет о том, что такое System Design и почему он важен, а также как пройти соответствующее интервью.
-

Время проведения: 13 мая 19:00 (МСК)
Формат: Онлайн (ссылка на встречу прилетит за час до митапа)

-
Занимаем места на митап!

🐦‍🔥 System Design Интервью. Мой первый fail, уроки и успешный фреймворк прохождения

Разберём завтра 🔘

Аррива!🌴💃

2-й сезон System Design Игры! Let's play!

📈 Пора бить рекорды прошлого сезона и показать, чья мозговая нейросеть работает активнее 🤯

😊 System Design World + Yandex Cloud + HighLoad++ объявляют новый архитектурный сезон!

В первом сезоне замечательная devrel Анастасия Маслова предложила раскатать игру ещё раз.
Предложено - сделано :)
У нас получилась бомбическая интеграция 🔨

😊 А что внутри?
1) Отборочный тур online для всех❗️Из любой точки мира🌎
2) Дополнительный раунд и призы от партнера — технологической платформы Yandex Cloud❗️
3) Offline финал на Saint HighLoad 22-23 июня❗️
4) Проходки для 4-х финалистов! Да-да! Мы договорились с HighLoad++ снизить цену с 78000 -> 0 рублей❗️

Как участвовать?
🔘Заполнить форму до 18.05
🔘По ней будет доступ и валидация в тг чате

Когда отборочный тур?
🔘Ориентировочно 21.05 (чт) вечером.

🕺 Вести игру буду я. Пошёл готовить вопросы 🤓
P.S. Можете предложить название секции. Вот какие были в 1-м сезоне.

Ой что намечается.🤯🔨
Хотим форму для участия?

❗️ Готовим кэш правильно!

📈С ростом нагрузки одни и те же запросы к БД становятся узким местом.
Кто обитает на дне океана🤨 поможет нам в такой ситуации?

❗️Кэш!
Ставим рядом с приложением и базой:
⁍ Горячие данные под рукой
⁍ В БД ходим только при необходимости

❓ Следующий вопрос - как правильно с ним взаимодействовать?
С новым элементом приходят три независимых вопроса:

∙ Как читать?
∙ Как писать?
∙ Как инвалидировать данные?

Для конкретной задачи - это три независимых выбора.
Правильный ответ зависит от приоритетов: консистентность, скорость, простота.

👩🏻‍🦰👨🏻‍🦰 Пример: профиль пользователя
Профиль читается очень часто, почти при каждом запросе (аватарка, имя, настройки). Меняется редко. Пользователь обновил данные в настройках. После изменения новое значение должно быть видно сразу.

1) Чтение. Выбираем паттерн Cache-Aside.
➕ Простая реализация: достаточно Redis и нескольких строк кода, без сложной обвязки.
➕ Устойчивость к падению кэша: если Redis недоступен, приложение продолжает работать через БД.
➖ Первый запрос к "холодному" ключу приводит к cache miss: запрос идёт в БД и только потом прогревает кэш.
2) Запись. Выбираем паттерн Write-Through.
➕ После успешной записи данные в кэше и БД сразу синхронизированы.
➕ Одна точка обновления: не нужно отдельно думать об инвалидации при записи.
➖ Запись медленнее: оплачиваем и кэш, и БД. Для частых записей это может быть критично, но у профиля записи редкие.
3) Инвалидация. Выбираем TTL (например, час).
В данном случае стратегия записи Write-Through обеспечивает актуальность данных в кэше. TTL можно добавить для автоматической очистки ключей по истечении времени жизни.

✍️ Вывод
У кэша нет "правильного" паттерна на все случаи.
Есть три направления: чтение, запись, инвалидация. Под каждую задачу собирается своя комбинация.