🏄‍♂️ Из аналитика ➡️ продакты. Оно того стоит?

🤘 С Андреем Бураковым мы познакомились на просторах телеграмм каналов, воркшопах по дизайну систем.
Заинтересовал его опыт. Путь в IT. А потом встретились лично как спикеры Dump'a.

🤔 Какой есть верный способ раскрыть специалиста?
Верно - пригласить на подкаст🤘

👋 Для вас, дорогие подписчики, путь Андрея:
ФизТех -> Разработка -> Аналитика -> Продакт менеджмент и не только
➕С мотивацией и поиском жизненного пути!
➕В ёмком последовательном изложение.

✔️ А также про работу под пальмами и сколько вообще денег у Аналитиков и Продактов. А главное - стоит ли переходить в другую проф. область?

◾️ Канал Андрея о технике и продуктах - another_sa:

➡️ Смотреть:
Youtube
Rutube

P.S. Пора ли менять специализацию в текущих реалиях?

1️⃣ Первая викторина по System Design состоялась!

🤩 Как это было
Понравилась story от Анастасии. Делюсь.

https://news.1rj.ru/str/anasta_see_u/s/182

Смотреть всё на —> RUTUBE <—

Кто уже посмотрел - ваши впечатления?)

1️⃣0️⃣ PostgreSQL и 10 млн записей. Всё плохо?

❌ Очень внезапно сайт стал медленно грузиться. Почему?
=> Перешагнули психологический рубеж в 10 млн записей.

Что при этом происходит:
• Индексы перестают помещаться в RAM
• Планировщик запросов выбирает неоптимальные пути
• Простые JOIN превращаются в многоминутные операции
• Главный запрос выполнялся 28 секунд 🐤

✅ Что сделали:
• Провели анализ — нашли самые тяжелые запросы через pg_stat_statements
• Оптимизировали индексы — заменили простые индексы на составные и частичные
• Переписали запрос — разбили на CTE для лучшей оптимизации
• Обновили статистику — ANALYZE для помощи планировщику

💯 Результат:
• Время запроса улучшилось: с 28 сек до 120 мс (в 233 раза)
• Чтение строк: с 15 млн до 8 тыс
• Нагрузка на CPU: с 95% до 12%

‼️ Главные выводы:
• Индексы ≠ волшебная палочка — нужно понимать, как их использует планировщик
• 10 млн — психологический барьер, после него меняется поведение СУБД
• Без EXPLAIN ANALYZE и pg_stat_statements работаешь вслепую
• Иногда проще переписать запрос, чем добавить очередной индекс

—> Полная версия на habr <—

👨‍🎓 Outbox Pattern для System Design Интервью

❌ Сервис успел записать заказ, но не отправил событие
=> Потерян заказ, двойное списание или не консистентное состояние между сервисами.

✅ Как исправить - Outbox Pattern 📦:
• Сохраняем событие в таблицу outbox в той же транзакции, что и заказ
• Отдельный Relay/Ретранслятор/Воркер вычитывает события и публикует их в брокер
• Даже если сервис упал, запись не теряется, воркер перешлёт повторно

⚙️ Семантика
• At-least-once между outbox и брокером
• Дубликаты как осознанный компромисс ради гарантированной доставки
• Exactly-once достигается за счёт идемпотентной обработки у потребителей

💡 Зачем знать
1) Паттерн Outbox является базовым инструментом в event-driven архитектуре и частым вопросом на System Design интервью.
2) Появляется в конце интервью. Когда стартуют вопросы про повышение отказоустойчивости системы.
3) Делает ваше прохождение сильней. Увеличивает шансы на успех.

‼️ Моя статья на хабр
С уже известной вам героиней:
Outbox pattern для System Design Интервью

🤩 System Design Викторина

Первая в рунете. А может даже и в мире!
В виде премьеры на youtube.

Сейчас
https://youtu.be/l5MEhajmHGI

🧐 Саботеры правят ТЗ

☀️ Этим летом Татьяна - автор канала "Семейка продактов" - пригласила рассказать про основы System Design своим подписчикам.
Мы сделали 2 встречи. Делился экспертизой с продакт менеджерами. Которым также стали давать System Design!

✨ Теперь я делюсь её активностью на HighLoad++ - "Саботеры правят ТЗ":
"Игра, в которой исполнитель задачи будет делать жизнеспособный продукт и противостоять саботёрам, вносящим правки в ТЗ."

🙂 Будете на конференции, заходите!

Подробности здесь:
https://highload.ru/moscow/2025/abstracts/16460

💡 Повезло оказаться в списке приглашенных на after party от yandex cloud после HighLoad++.
Результатом доволен.