⚡ 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
🌞 Доброе утро! Пока вы разбираетесь с делами, соцсети снова и снова подсовывают мне одну и ту же новость… Ну что ж, поделюсь.
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
👍1
🚀 Нейросеть за $50. Технологии становятся дешевле или хуже?
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
TechCrunch
Researchers created an open rival to OpenAI's o1 'reasoning' model for under $50 | TechCrunch
AI researchers at Stanford and the University of Washington were able to train an AI "reasoning" model for under $50 in cloud compute credits, according
👍1
🛠 Битва языков: Rust vs C в контексте Linux
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
👍1
🚀 Мизулина предложила разблокировать X (бывший Twitter) в России — мол, теперь там меньше цензуры и деструктива.
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
👍2
📱 Цифровой шаббат: мозгам тоже нужен выходной
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
🔥1
💡 Почему так много языков программирования?
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
❤1
💻 Кто такие DevOps?
Если спросить разработчика: "Кто такой DevOps?", то можно услышать что-то вроде:
👨💻 "Ну… это админ, который знает не только bash, но и Python, а иногда даже Go!"
В общем-то, не без правды. Но DevOps — это не должность, а культура и подход. Это когда код не просто пишется, а автоматически тестируется, деплоится и масштабируется без боли и страданий.
🚀 Что делает DevOps?
🔹 CI/CD – настраивает конвейер доставки кода (GitLab CI, Jenkins, GitHub Actions), чтобы каждое изменение залетало в прод без магии шаманов.
🔹 Контейнеризация – заворачивает приложения в Docker, а потом ставит их в Kubernetes, чтобы они не падали при первом же нагрузочном тесте.
🔹 Мониторинг и логирование – разворачивает Prometheus, Grafana, Loki, чтобы никто не бегал по серверу с grep’ом в поисках "почему всё упало".
🔹 Автоматизация инфраструктуры – Terraform, Ansible, Helm – всё, что избавляет от ручной настройки серверов, которые "работают, но лучше не трогать".
🔹 Облачные технологии – Selectel, Yandex Cloud, Cloud.ru – чтобы можно было за 5 минут развернуть 100 серверов, а потом за 10 секунд их удалить, когда приходит счёт за облако 😅.
🤔 А DevOps – это команда или один человек?
Есть две модели:
1️⃣ DevOps-команда – отдельный отдел, который обслуживает несколько команд разработки. Минус – часто становится бутылочным горлышком.
2️⃣ DevOps в команде разработки – тогда DevOps-инженер встроен в продуктовую команду и решает задачи конкретного продукта. Это быстрее, но требует хорошего уровня скилла от разработчиков.
🧐 А что по зарплатам?
Ну… если видишь DevOps, который не спешит менять работу – значит, у него либо зарплата хорошая, либо мониторинг настроен идеально 😆
А как у вас? DevOps – это отдельная команда или интегрированы в разработку? 🚀
#толки
Если спросить разработчика: "Кто такой DevOps?", то можно услышать что-то вроде:
👨💻 "Ну… это админ, который знает не только bash, но и Python, а иногда даже Go!"
В общем-то, не без правды. Но DevOps — это не должность, а культура и подход. Это когда код не просто пишется, а автоматически тестируется, деплоится и масштабируется без боли и страданий.
🚀 Что делает DevOps?
🔹 CI/CD – настраивает конвейер доставки кода (GitLab CI, Jenkins, GitHub Actions), чтобы каждое изменение залетало в прод без магии шаманов.
🔹 Контейнеризация – заворачивает приложения в Docker, а потом ставит их в Kubernetes, чтобы они не падали при первом же нагрузочном тесте.
🔹 Мониторинг и логирование – разворачивает Prometheus, Grafana, Loki, чтобы никто не бегал по серверу с grep’ом в поисках "почему всё упало".
🔹 Автоматизация инфраструктуры – Terraform, Ansible, Helm – всё, что избавляет от ручной настройки серверов, которые "работают, но лучше не трогать".
🔹 Облачные технологии – Selectel, Yandex Cloud, Cloud.ru – чтобы можно было за 5 минут развернуть 100 серверов, а потом за 10 секунд их удалить, когда приходит счёт за облако 😅.
🤔 А DevOps – это команда или один человек?
Есть две модели:
1️⃣ DevOps-команда – отдельный отдел, который обслуживает несколько команд разработки. Минус – часто становится бутылочным горлышком.
2️⃣ DevOps в команде разработки – тогда DevOps-инженер встроен в продуктовую команду и решает задачи конкретного продукта. Это быстрее, но требует хорошего уровня скилла от разработчиков.
🧐 А что по зарплатам?
Ну… если видишь DevOps, который не спешит менять работу – значит, у него либо зарплата хорошая, либо мониторинг настроен идеально 😆
А как у вас? DevOps – это отдельная команда или интегрированы в разработку? 🚀
#толки
Доброе утро! ☕️ Маск снова в деле — он хочет купить OpenAI и вернуть компанию к опенсорсу.
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
👍1
🏗 DDD — от теории к практике: что это и как его внедрять
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
/src
├── /order # Контекст "Заказы"
│ ├── /application # Сценарии использования (Use Cases)
│ │ ├── PlaceOrderHandler.py
│ │ ├── CancelOrderHandler.py
│ ├── /domain # Бизнес-логика
│ │ ├── /models # Entities и Value Objects
│ │ │ ├── Order.py
│ │ │ ├── OrderItem.py
│ │ │ ├── OrderStatus.py
│ │ ├── /services # Бизнес-сервисы (доменные)
│ │ │ ├── OrderService.py
│ │ │ ├── DiscountCalculator.py
│ │ ├── /events # Доменные события
│ │ │ ├── OrderPlaced.py
│ │ │ ├── OrderCancelled.py
│ │ ├── /repositories # Абстракция работы с БД
│ │ │ ├── OrderRepository.py
│ ├── /infrastructure # Взаимодействие с внешним миром
│ │ ├── /persistence # Реализация репозиториев
│ │ │ ├── OrderSQLRepository.py
│ │ ├── /messaging # Интеграция с брокерами событий
│ │ │ ├── KafkaPublisher.py
│ │ ├── /external # API-запросы к сторонним сервисам
│ │ │ ├── PaymentGateway.py
│ ├── /presentation # API-интерфейсы
│ │ ├── /http # REST API
│ │ │ ├── OrderController.py
│ │ ├── /cli # Консольные команды
│ │ │ ├── ImportOrders.py
│ │ ├── /events # Обработчики событий
│ │ │ ├── OrderPlacedListener.py
├── /customer # Контекст "Клиенты"
├── /billing # Контекст "Биллинг"
├── /shared # Общий код между контекстами
│ ├── /kernel # Базовые интерфейсы и абстракции
│ ├── /events # Кросс-доменные события
│ ├── /utils # Хелперы и вспомогательные классы
├── main.py # Точка входа
├── settings.py # Конфигурация
└── requirements.txt # Зависимости