Пирамида тестирования мужчины 💪
Все знают классическую пирамиду тестирования, но, как показывает практика, она не всегда спасает от багов.
Реальный мир сложнее, и если хочешь спать спокойно, лучше добавить ещё несколько уровней.
Дополняем пирамиду тестирования
✅ Контрактные тесты
Любая интеграция — это источник боли, если не тестировать контракты. Будь то API (Swagger, OpenAPI), события в Kafka (Avro, Apicurio) или даже схемы в MongoDB — если контракт нарушен, тебя ждёт продакшн-ад.
✅ Тесты на кодстайл
Линтеры — это не просто про пробелы и запятые. Они помогают держать код в едином стиле и предотвращать базовые ошибки ещё до того, как ты задумаешься о логике.
✅ Архитектурные тесты
Если ты не хочешь, чтобы через полгода твой проект выглядел как Франкенштейн, стоит следить за архитектурой. В JVM-мире, например, есть ArchUnit, который позволяет чётко задать границы между слоями и контролировать зависимости.
Когда писать тесты?
Есть мнение, что тесты нужны только там, где появляется бизнес-логика, а вначале можно забить. Я категорически не согласен.
Чаще всего на старте проект в руках 2-3 человек, и чем больше автоматических проверок, тем выше качество на выходе. Меньше ручного тестирования — быстрее фичи в прод.
🔥 Отдельно хочу автоматизировать проверку уязвимостей, но вот всё руки не доходят… Но когда-нибудь я до этого доберусь. 😏
👉 А какие уровни тестирования добавляешь ты? Может, есть любимые инструменты, которые помогают не ловить баги на проде? Делись в комментах! 🚀
#тек
Все знают классическую пирамиду тестирования, но, как показывает практика, она не всегда спасает от багов.
End-to-End Tests
▲
│
Integration Tests
▲
│
Unit Tests
Реальный мир сложнее, и если хочешь спать спокойно, лучше добавить ещё несколько уровней.
Дополняем пирамиду тестирования
✅ Контрактные тесты
Любая интеграция — это источник боли, если не тестировать контракты. Будь то API (Swagger, OpenAPI), события в Kafka (Avro, Apicurio) или даже схемы в MongoDB — если контракт нарушен, тебя ждёт продакшн-ад.
✅ Тесты на кодстайл
Линтеры — это не просто про пробелы и запятые. Они помогают держать код в едином стиле и предотвращать базовые ошибки ещё до того, как ты задумаешься о логике.
✅ Архитектурные тесты
Если ты не хочешь, чтобы через полгода твой проект выглядел как Франкенштейн, стоит следить за архитектурой. В JVM-мире, например, есть ArchUnit, который позволяет чётко задать границы между слоями и контролировать зависимости.
Когда писать тесты?
Есть мнение, что тесты нужны только там, где появляется бизнес-логика, а вначале можно забить. Я категорически не согласен.
Чаще всего на старте проект в руках 2-3 человек, и чем больше автоматических проверок, тем выше качество на выходе. Меньше ручного тестирования — быстрее фичи в прод.
🔥 Отдельно хочу автоматизировать проверку уязвимостей, но вот всё руки не доходят… Но когда-нибудь я до этого доберусь. 😏
👉 А какие уровни тестирования добавляешь ты? Может, есть любимые инструменты, которые помогают не ловить баги на проде? Делись в комментах! 🚀
#тек
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Чуть-чуть 🤏 моего 📱 тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🧨 DeepSeek взломали, но не хакеры, а сами разработчики
Исследователи из Wiz Research случайно наткнулись на базу данных, которая была вообще без защиты 😳
В открытом доступе болтались:
🔑 Секретные ключи
💬 Незашифрованные чаты
📜 Логи и бэкенд
Пока DeepSeek роняет фондовый рынок, его данные просто лежат открытыми, как скидочный промокод в паблике ВК 😅
#новости
Исследователи из Wiz Research случайно наткнулись на базу данных, которая была вообще без защиты 😳
В открытом доступе болтались:
🔑 Секретные ключи
💬 Незашифрованные чаты
📜 Логи и бэкенд
Пока DeepSeek роняет фондовый рынок, его данные просто лежат открытыми, как скидочный промокод в паблике ВК 😅
#новости
👍1
Про курение 🚬
С 14 до 30 лет я курил. Потом просто взял и бросил – легко, без ломки и страданий. Но про то, как я это сделал, расскажу в другой раз (а может, даже завтра).
Сегодня о другом. Как бы там ни было, но когда я начинал, курение было крутым. Сигарета в руке – будто символ взрослости и дерзости. А теперь? Сначала всех подсадили, а потом объявили курильщиков изгоями. Курить можно только в специально отведенных местах, забившись в аквариумную комнатку на морозе или в подвале, под укоризненные взгляды проходящих мимо людей.
Но если откинуть все это, курение мне реально помогало.
🔥 На заводе курилка была местом, где рождались и умирали самые сочные новости. Пока до всех доходила официальная версия событий, мы уже знали инсайды, детали и то, что не скажут начальники. Там же я понял одну важную штуку: повышают не тех, кто лучше работает, а тех, кого чаще видят и с кем общаются.
🔥 В IT я применил этот опыт. Будучи джуном, я в курилке ловил холиварные темы, о которых даже не знал. Кто-то спорил про чистую архитектуру, кто-то хейтил определенный стек, кто-то рассказывал, как вчера всё уронили в проде – и ты начинаешь разбираться в том, чего не знал, просто слушая разговоры.
🔥 В жизни курение стало социальной смазкой. Ты выходишь на улицу, стоишь с незнакомым человеком, достаёшь сигарету – и вот уже завязывается разговор. В каком еще формате можно так легко и непринужденно заговорить с кем угодно?
Курение – вредная штука, но когда-то это был мой лайфхак для нетворкинга и прокачки социалки. Сейчас, конечно, всё поменялось, но суть осталась той же: чем больше ты в общении, тем быстрее растешь.
А какие у тебя были неожиданные инструменты для прокачки карьеры и соцнавыков?
#bio
С 14 до 30 лет я курил. Потом просто взял и бросил – легко, без ломки и страданий. Но про то, как я это сделал, расскажу в другой раз (а может, даже завтра).
Сегодня о другом. Как бы там ни было, но когда я начинал, курение было крутым. Сигарета в руке – будто символ взрослости и дерзости. А теперь? Сначала всех подсадили, а потом объявили курильщиков изгоями. Курить можно только в специально отведенных местах, забившись в аквариумную комнатку на морозе или в подвале, под укоризненные взгляды проходящих мимо людей.
Но если откинуть все это, курение мне реально помогало.
🔥 На заводе курилка была местом, где рождались и умирали самые сочные новости. Пока до всех доходила официальная версия событий, мы уже знали инсайды, детали и то, что не скажут начальники. Там же я понял одну важную штуку: повышают не тех, кто лучше работает, а тех, кого чаще видят и с кем общаются.
🔥 В IT я применил этот опыт. Будучи джуном, я в курилке ловил холиварные темы, о которых даже не знал. Кто-то спорил про чистую архитектуру, кто-то хейтил определенный стек, кто-то рассказывал, как вчера всё уронили в проде – и ты начинаешь разбираться в том, чего не знал, просто слушая разговоры.
🔥 В жизни курение стало социальной смазкой. Ты выходишь на улицу, стоишь с незнакомым человеком, достаёшь сигарету – и вот уже завязывается разговор. В каком еще формате можно так легко и непринужденно заговорить с кем угодно?
Курение – вредная штука, но когда-то это был мой лайфхак для нетворкинга и прокачки социалки. Сейчас, конечно, всё поменялось, но суть осталась той же: чем больше ты в общении, тем быстрее растешь.
А какие у тебя были неожиданные инструменты для прокачки карьеры и соцнавыков?
#bio
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
30PARA
или как я навел порядок в заметках (и не только)
Сколько раз у вас было такое: открыл Obsidian, а там полный хаос? В одной заметке мысли по проекту, в другой — случайные цитаты, где-то ссылка на статью, которая «точно пригодится» (но ты уже забыл, зачем). У меня так было постоянно. Решил, что пора с этим что-то делать, и наткнулся на метод PARA от Тиаго Форте.
⚡ В чем суть? Все заметки (да и вообще любая информация) делятся на 4 категории:
📂 Projects (Проекты) — текущие задачи с четким результатом.
Что у меня в этой папке?
Разработка Telegram-бота — заметки по архитектуре, багам, идеи по фичам.
Подготовка к конференции — тезисы выступления, список примеров, которые хочу использовать.
Продвижение блога — контент-план, идеи для постов, статистика.
📂 Areas (Области ответственности) — долгосрочные сферы жизни.
Что у меня в этой папке?
Фитнес — программа тренировок, прогресс, заметки по питанию.
Финансы — личный бюджет, инвестиции, список крупных целей.
Развитие — книги, которые читаю, идеи для новых навыков.
📂 Resources (Ресурсы) — полезные материалы без привязки к дедлайнам.
Что у меня тут?
Конспекты книг — краткие выводы, чтобы не перечитывать заново.
Статьи по разработке — крутые гайды, которые стоит изучить.
Шаблоны и чек-листы — например, как быстро собрать лендинг или подготовиться к переговорам.
📂 Archive (Архив) — то, что уже не актуально, но может пригодиться.
Что я туда отправил?
Старые проекты — дипломная работа, идеи, которые пока не реализовал.
Заметки по прошлым курсам — мало ли, вдруг когда-то снова понадобится.
Старые планы и цели — интересно иногда пересматривать и анализировать.
Сначала я навел порядок только в Obsidian, но потом понял, что это реально удобно. В итоге:
✅ Файлы на ноуте теперь тоже разложены по этой системе.
✅ Закладки в браузере разбиты по тем же категориям (вместо тысяч «прочитать потом»).
✅ Даже в голове стало легче — когда знаешь, где искать нужную инфу, мозг не перегревается.
Если у вас тоже цифровой бардак — попробуйте PARA. Внедряется за 30 минут, а пользы на годы вперед. 🚀
#толки
или как я навел порядок в заметках (и не только)
Сколько раз у вас было такое: открыл Obsidian, а там полный хаос? В одной заметке мысли по проекту, в другой — случайные цитаты, где-то ссылка на статью, которая «точно пригодится» (но ты уже забыл, зачем). У меня так было постоянно. Решил, что пора с этим что-то делать, и наткнулся на метод PARA от Тиаго Форте.
⚡ В чем суть? Все заметки (да и вообще любая информация) делятся на 4 категории:
📂 Projects (Проекты) — текущие задачи с четким результатом.
Что у меня в этой папке?
Разработка Telegram-бота — заметки по архитектуре, багам, идеи по фичам.
Подготовка к конференции — тезисы выступления, список примеров, которые хочу использовать.
Продвижение блога — контент-план, идеи для постов, статистика.
📂 Areas (Области ответственности) — долгосрочные сферы жизни.
Что у меня в этой папке?
Фитнес — программа тренировок, прогресс, заметки по питанию.
Финансы — личный бюджет, инвестиции, список крупных целей.
Развитие — книги, которые читаю, идеи для новых навыков.
📂 Resources (Ресурсы) — полезные материалы без привязки к дедлайнам.
Что у меня тут?
Конспекты книг — краткие выводы, чтобы не перечитывать заново.
Статьи по разработке — крутые гайды, которые стоит изучить.
Шаблоны и чек-листы — например, как быстро собрать лендинг или подготовиться к переговорам.
📂 Archive (Архив) — то, что уже не актуально, но может пригодиться.
Что я туда отправил?
Старые проекты — дипломная работа, идеи, которые пока не реализовал.
Заметки по прошлым курсам — мало ли, вдруг когда-то снова понадобится.
Старые планы и цели — интересно иногда пересматривать и анализировать.
Сначала я навел порядок только в Obsidian, но потом понял, что это реально удобно. В итоге:
✅ Файлы на ноуте теперь тоже разложены по этой системе.
✅ Закладки в браузере разбиты по тем же категориям (вместо тысяч «прочитать потом»).
✅ Даже в голове стало легче — когда знаешь, где искать нужную инфу, мозг не перегревается.
Если у вас тоже цифровой бардак — попробуйте PARA. Внедряется за 30 минут, а пользы на годы вперед. 🚀
#толки
👍1
DevEx? а я думал сова 🦉
Сегодня наткнулся на статью про Developer Experience (DevEx) и подумал: «О, что-то новенькое!». Но чем дальше читал, тем больше понимал — это просто модное название для адекватно настроенных рабочих процессов.
То есть, представь себе компанию, где:
✅ Рабочее окружение настраивается за 5 минут, а не за неделю.
✅ Доступы выдаются автоматически, а не через квест с тремя согласованиями.
✅ Деплой понятен даже джуну, а не превращается в «давай позовем DevOps».
✅ Метрики доступны, логирование удобное, а не «ну посмотри в Kibana, только тебе туда пока доступа нет».
Это не DevEx, это нормальная разработка.
❌ Почему DevEx вообще обсуждают?
Потому что многие разработчики до сих пор:
🚧 Тратят часы (а то и дни) на настройку окружения.
🚧 Страдают с деплоем из-за ошибок вроде «не та версия библиотеки» или «нужно пересобрать вручную».
🚧 Не видят, что происходит на проде, потому что «метрики у админов».
🚧 Вынуждены заполнять заявки, чтобы просто начать работать.
И все это в компаниях, которые вешают на офисные стены слова «инновации» и «эффективность».
🔥 Почему это вообще проблема?
Потому что плохой DevEx — это не просто раздражающий геморрой. Это:
⚡ Упущенная прибыль, когда разработчики решают не бизнес-задачи, а бюрократию.
⚡ Выгорание, когда даже простая задача превращается в мучение.
⚡ Текучка кадров, потому что никто не хочет страдать.
Но компании почему-то думают, что бесплатные печеньки и корпоративный фитнес это решат.
💡 Что с этим делать?
В идеальном мире DevEx даже не должен быть темой разговора, потому что нормальные процессы должны быть стандартом.
Но раз уж мы живем не в идеальном мире, вот что поможет:
✔ Автоматизировать рутинные процессы: CI/CD, выдача доступов, настройка окружения.
✔ Давать разработчикам информацию, а не прятать метрики за семью паролями.
✔ Упрощать деплой и тестирование, а не превращать их в квест.
✔ Слушать разработчиков, а не только топ-менеджмент.
🎯 Итог: это не DevEx, а просто нормальная разработка
Если в вашей компании говорят «мы улучшаем DevEx», это, скорее всего, значит «мы просто пытаемся сделать так, чтобы работа не была болью».
Как у вас с этим? Делитесь в комментах! 👇
#толки
Сегодня наткнулся на статью про Developer Experience (DevEx) и подумал: «О, что-то новенькое!». Но чем дальше читал, тем больше понимал — это просто модное название для адекватно настроенных рабочих процессов.
То есть, представь себе компанию, где:
✅ Рабочее окружение настраивается за 5 минут, а не за неделю.
✅ Доступы выдаются автоматически, а не через квест с тремя согласованиями.
✅ Деплой понятен даже джуну, а не превращается в «давай позовем DevOps».
✅ Метрики доступны, логирование удобное, а не «ну посмотри в Kibana, только тебе туда пока доступа нет».
Это не DevEx, это нормальная разработка.
❌ Почему DevEx вообще обсуждают?
Потому что многие разработчики до сих пор:
🚧 Тратят часы (а то и дни) на настройку окружения.
🚧 Страдают с деплоем из-за ошибок вроде «не та версия библиотеки» или «нужно пересобрать вручную».
🚧 Не видят, что происходит на проде, потому что «метрики у админов».
🚧 Вынуждены заполнять заявки, чтобы просто начать работать.
И все это в компаниях, которые вешают на офисные стены слова «инновации» и «эффективность».
🔥 Почему это вообще проблема?
Потому что плохой DevEx — это не просто раздражающий геморрой. Это:
⚡ Упущенная прибыль, когда разработчики решают не бизнес-задачи, а бюрократию.
⚡ Выгорание, когда даже простая задача превращается в мучение.
⚡ Текучка кадров, потому что никто не хочет страдать.
Но компании почему-то думают, что бесплатные печеньки и корпоративный фитнес это решат.
💡 Что с этим делать?
В идеальном мире DevEx даже не должен быть темой разговора, потому что нормальные процессы должны быть стандартом.
Но раз уж мы живем не в идеальном мире, вот что поможет:
✔ Автоматизировать рутинные процессы: CI/CD, выдача доступов, настройка окружения.
✔ Давать разработчикам информацию, а не прятать метрики за семью паролями.
✔ Упрощать деплой и тестирование, а не превращать их в квест.
✔ Слушать разработчиков, а не только топ-менеджмент.
🎯 Итог: это не DevEx, а просто нормальная разработка
Если в вашей компании говорят «мы улучшаем DevEx», это, скорее всего, значит «мы просто пытаемся сделать так, чтобы работа не была болью».
Как у вас с этим? Делитесь в комментах! 👇
#толки
👍1
💨 Как я бросил курить и почему это оказалось проще, чем казалось
В одном из прошлых постов я обещал рассказать, как прошел путь от заядлого курильщика до человека, который уже почти три года не берет сигарету в руки.
С тех пор в моей жизни многое изменилось: привычки, режим, осознанность. Но сегодня не об этом. Сегодня — о том, как я быстро и окончательно бросил курить и какие выводы сделал.
🚬 Курил, пытался бросить, курил снова
Как и все курильщики, я много раз говорил себе: «Все, завязываю». Но каждый раз заканчивалось примерно одинаково: ритуальное «последнее» стреляние сигарет, несколько дней без табака, потом «одну и всё» — и привет, старые привычки.
Но однажды что-то изменилось.
👶 Узнал, что стану отцом
Когда я узнал, что скоро у меня родится ребенок, в голове запустился необратимый процесс осознания ответственности. И первое, что я решил — бросить курить.
Раз уж все советуют книгу Алана Карра, я выбрал аудиоверсию и стал слушать её во время прогулок с собакой… куря при этом сигарету.
🧠 Одна мысль, которая перевернула всё
По ходу книги автор повторяет: курильщик должен прийти к последней сигарете осознанно и покурить её в финале книги. Я готовился.
Но в какой-то момент услышал вопрос:
— Чего хочет читатель книги?
— Бросить курить.
— Чего хочет курильщик?
— Курить.
❗ То есть я одновременно хочу бросить курить и хочу курить. Это же нелогично. Так не может быть.
В этот момент у меня в голове случился щелчок: чего я действительно хочу?
И… я просто перестал курить. Даже не дослушал книгу.
🔥 Главный вывод
Все получится, если ты действительно этого хочешь.
Я вспоминаю себя в прошлом и понимаю: если я хотел курить — я курил. Всегда.
В аэропорту? В туалете.
В поезде? Между вагонов.
Где нельзя? Придумывал, как можно.
И тогда я понял: если я действительно хочу не курить, то это должно работать точно так же.
Хочешь курить — куришь. Не хочешь — не куришь. Всё просто.
Бросить курить оказалось проще, чем пытаться бросить.
#bio
В одном из прошлых постов я обещал рассказать, как прошел путь от заядлого курильщика до человека, который уже почти три года не берет сигарету в руки.
С тех пор в моей жизни многое изменилось: привычки, режим, осознанность. Но сегодня не об этом. Сегодня — о том, как я быстро и окончательно бросил курить и какие выводы сделал.
🚬 Курил, пытался бросить, курил снова
Как и все курильщики, я много раз говорил себе: «Все, завязываю». Но каждый раз заканчивалось примерно одинаково: ритуальное «последнее» стреляние сигарет, несколько дней без табака, потом «одну и всё» — и привет, старые привычки.
Но однажды что-то изменилось.
👶 Узнал, что стану отцом
Когда я узнал, что скоро у меня родится ребенок, в голове запустился необратимый процесс осознания ответственности. И первое, что я решил — бросить курить.
Раз уж все советуют книгу Алана Карра, я выбрал аудиоверсию и стал слушать её во время прогулок с собакой… куря при этом сигарету.
🧠 Одна мысль, которая перевернула всё
По ходу книги автор повторяет: курильщик должен прийти к последней сигарете осознанно и покурить её в финале книги. Я готовился.
Но в какой-то момент услышал вопрос:
— Чего хочет читатель книги?
— Бросить курить.
— Чего хочет курильщик?
— Курить.
❗ То есть я одновременно хочу бросить курить и хочу курить. Это же нелогично. Так не может быть.
В этот момент у меня в голове случился щелчок: чего я действительно хочу?
И… я просто перестал курить. Даже не дослушал книгу.
🔥 Главный вывод
Все получится, если ты действительно этого хочешь.
Я вспоминаю себя в прошлом и понимаю: если я хотел курить — я курил. Всегда.
В аэропорту? В туалете.
В поезде? Между вагонов.
Где нельзя? Придумывал, как можно.
И тогда я понял: если я действительно хочу не курить, то это должно работать точно так же.
Хочешь курить — куришь. Не хочешь — не куришь. Всё просто.
Бросить курить оказалось проще, чем пытаться бросить.
#bio
❤1👍1
☀️ Доброе утро! Мир снова стал чуть более киберпанковым.
Google тихо удалил из своих принципов запрет на создание ИИ для оружия.
📌 Бывший глава команды по этике ИИ:
🤖 Мы шутили про Skynet, но, похоже, ИИ перестает шутить.
А пока — хорошего дня! 💀
Google тихо удалил из своих принципов запрет на создание ИИ для оружия.
📌 Бывший глава команды по этике ИИ:
Google теперь, вероятно, будет разрабатывать технологии, которые могут убивать людей.
🤖 Мы шутили про Skynet, но, похоже, ИИ перестает шутить.
А пока — хорошего дня! 💀
👍1👀1
⚡ Outbox-паттерн: спасение от потерянных событий (и денег)
В одном из первых постов я рассказывал, как из-за моей ошибки контора потеряла 10к $. Тогда я отправлял события в очередь до записи в БД. Запрос к БД упал, а уведомление уже улетело в платежный сервис. В итоге деньги списали, но не зафиксировали в системе, а потом это повторилось еще много-много раз.
Если бы тогда использовали реляционную БД и Outbox-паттерн, этого бы не случилось.
🤔 В чем проблема?
Типичная схема взаимодействия с брокером:
1️⃣ Пишем данные в БД
2️⃣ Отправляем событие в очередь
Но что если брокер упал или вызов события не прошел после успешного коммита в БД? Система потеряет важное уведомление, а другой сервис никогда не узнает об изменениях.
Решения без Outbox:
🔹 Повторять отправку? — Дубликаты и сложность в обработке
🔹 Держать транзакцию до подтверждения от брокера? — Тормоза в БД
🔹 Игнорировать? — Потерянные данные и баги
🛠 Как решает Outbox?
Вместо того чтобы сразу пушить событие:
✅ Записываем его в специальную таблицу (outbox) в той же транзакции, что и изменение данных
✅ Отдельный процесс (consumer, cron-job, Debezium) читает outbox и отправляет события в брокер
✅ После успешной отправки удаляем запись из outbox
🎯 Почему это круто?
✔️ Гарантия доставки — без потерь, даже если брокер лег
✔️ Идемпотентность — события можно повторно обработать без дубликатов
✔️ Разделение ответственности — бизнес-логика в одном месте, отправка в другом
🚀 Когда использовать?
✔ Если твои сервисы взаимодействуют через event-driven архитектуру
✔ Если тебе нужно гарантированно отправлять события, даже при сбоях
✔ Если ты используешь реляционную БД и хочешь избавиться от сложностей с distributed transactions
Если бы у нас тогда был Outbox + реляционная БД, я бы просто записал событие в outbox в одной транзакции с изменением данных. Даже если бы платежный сервис упал, событие никуда бы не пропало — оно бы отправилось при следующей обработке.
Вывод: если работаешь с реляционной БД и событиями — Outbox обязателен. Уже используешь или пока надеешься на удачу? Давай обсудим в комментах! 💬
#тек
В одном из первых постов я рассказывал, как из-за моей ошибки контора потеряла 10к $. Тогда я отправлял события в очередь до записи в БД. Запрос к БД упал, а уведомление уже улетело в платежный сервис. В итоге деньги списали, но не зафиксировали в системе, а потом это повторилось еще много-много раз.
Если бы тогда использовали реляционную БД и Outbox-паттерн, этого бы не случилось.
🤔 В чем проблема?
Типичная схема взаимодействия с брокером:
1️⃣ Пишем данные в БД
2️⃣ Отправляем событие в очередь
Но что если брокер упал или вызов события не прошел после успешного коммита в БД? Система потеряет важное уведомление, а другой сервис никогда не узнает об изменениях.
Решения без Outbox:
🔹 Повторять отправку? — Дубликаты и сложность в обработке
🔹 Держать транзакцию до подтверждения от брокера? — Тормоза в БД
🔹 Игнорировать? — Потерянные данные и баги
🛠 Как решает Outbox?
Вместо того чтобы сразу пушить событие:
✅ Записываем его в специальную таблицу (outbox) в той же транзакции, что и изменение данных
✅ Отдельный процесс (consumer, cron-job, Debezium) читает outbox и отправляет события в брокер
✅ После успешной отправки удаляем запись из outbox
🎯 Почему это круто?
✔️ Гарантия доставки — без потерь, даже если брокер лег
✔️ Идемпотентность — события можно повторно обработать без дубликатов
✔️ Разделение ответственности — бизнес-логика в одном месте, отправка в другом
🚀 Когда использовать?
✔ Если твои сервисы взаимодействуют через event-driven архитектуру
✔ Если тебе нужно гарантированно отправлять события, даже при сбоях
✔ Если ты используешь реляционную БД и хочешь избавиться от сложностей с distributed transactions
Если бы у нас тогда был Outbox + реляционная БД, я бы просто записал событие в outbox в одной транзакции с изменением данных. Даже если бы платежный сервис упал, событие никуда бы не пропало — оно бы отправилось при следующей обработке.
Вывод: если работаешь с реляционной БД и событиями — Outbox обязателен. Уже используешь или пока надеешься на удачу? Давай обсудим в комментах! 💬
#тек
👍1
🚨 DeepSeek приостанавливает платежи за API
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Bloomberg.com
DeepSeek Limits Access to AI Model as Demand Strains Capacity
DeepSeek, the Chinese startup whose artificial-intelligence model roiled global markets last week, said it would restrict access to its application programming interface service because of shortages with its server capacity.
👍1