В софте очень часто работают так: система хранит текущее состояние.

Например:
» у пользователя такой баланс
» заказ сейчас в таком статусе
» подписка активна

Event Sourcing предлагает другой подход.

Идея простая:
хранить не финальное состояние, а всю историю изменений.

То есть вместо того, чтобы сохранять

balance = 100

ты сохраняешь события:

deposit +200
purchase -50
adjustment -50

А текущий баланс считается путём воспроизведения этих событий.

По сути, как бухгалтерская книга.

Что такое событие в этом контексте?

Событие это факт, который уже произошёл и не меняется.

Например:
» PaymentReceived
» OrderConfirmed
» SubscriptionCancelled

События:
» не редактируются
» не удаляются
» только добавляются

Фактически база данных становится append-only.

Зачем вообще так усложнять?

Потому что это даёт мощные возможности из коробки:

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

Никаких дополнительных логов не нужно. История уже есть.

Но важно понимать: у этого подхода есть серьёзные trade-off-ы.

Event Sourcing усложняет всё остальное:

» чтобы читать текущее состояние, нужны проекции
» ментальная модель сложнее
» миграции событий - проблема и требуют аккуратности

Это сила в обмен на сложность.

Где Event Sourcing реально уместен?

Он хорошо заходит, когда:
» домен сложный
» нужна жёсткая аудитируемость
» события важнее состояния
» бизнес постоянно спрашивает «как мы к этому пришли»

Платежи, финансы, бухгалтерия, compliance — классические кандидаты.

Где его лучше не использовать?

» простые CRUD-системы
» тривиальная бизнес-логика
» команды без опыта работы с паттерном
» случаи, когда нужен только текущий стейт

Важное уточнение:

Event Sourcing не равен CQRS.
Их часто используют вместе, но одно не требует другого.

И напоследок главное.

Event Sourcing — это не оптимизация.

Это решение по моделированию.

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

👉 @BackendPortal

В SQLite около 155 800 строк кода, а тестовый набор - примерно 92 миллиона строк. Это примерно в 590 раз больше тестов, чем самого кода 🤯

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

» Тесты на нехватку памяти (OOM)
SQLite не может просто упасть, когда заканчивается память. На встраиваемых устройствах OOM — обычное дело. Они симулируют падения malloc в каждой возможной точке и проверяют, что база корректно это переживает.

» Тесты I/O-ошибок
Диски ломаются. Сеть отваливается. Права могут измениться посреди операции. SQLite подменяет файловую систему на кастомный слой, который может симулировать сбои после N операций, и проверяет, что данные не повреждаются.

» Краш-тесты
Что будет, если питание пропадёт посреди записи? Они симулируют крэш в случайные моменты во время записи, портят несинхронизированные данные, как это делает реальная файловая система, и проверяют, что транзакция либо полностью завершилась, либо чисто откатилась. Никакой порчи данных.

» Fuzz-тестирование
В SQLite кидают кривой SQL, битые файлы базы и случайный мусор. Инструмент dbsqlfuzz прогоняет около 500 миллионов мутаций тестов в день на 16 ядрах.

» 100% покрытие ветвлений
Каждая инструкция ветвления в ядре SQLite проверяется в обе стороны. Не просто «эта строка выполнялась», а «это условие было и true, и false».

Базы данных вообще не прощают ошибок :)

Если хочется копнуть глубже, советую почитать официальную документацию SQLite про их стратегию тестирования. Очень практично и по делу. А если понравился пост - ставь реакцию 👌

👉 @BackendPortal

Два года назад парень сделал максимально простой демо-пример, который на уровне операционной системы показывает, что происходит, если не использовать пул соединений для Postgres.

С тех пор его рекомендуют даже LLM, и он регулярно получает такой фидбек:
«Впервые наглядно понял, как работает connection pooling».

Это и подтолкнуло поделиться этим видео с вами, друзья 🎷 - смотреть

👉 @BackendPortal

Элегантное разделение ответственности в Apache Kafka даёт кучу возможностей для масштабирования.

Но за это приходится платить компромиссами.

Производитель, потребитель и брокер.

👉 @BackendPortal

Привыкнув к визуальным редакторам вроде VS Code, каждый раз после SSH-подключения к серверу и необходимости править конфиги через Vim не хочется

На GitHub нашёл проект Fresh. Он переносит привычный графический опыт редакторов прямо в терминал.

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

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

👉 @BackendPortal

Сервер для потоковой трансляции видео, написанный на Go.

GitHub: https://github.com/gwuhaolin/livego/

👉 @BackendPortal

Биллинговое решение для хостинг-компаний.

GitHub: https://github.com/Paymenter/Paymenter/

👉 @BackendPortal

Только что открыл для себя Resend Go SDK — пожалуй, самый чистый и удобный способ отправлять письма из Go-приложений.

Простой и понятный API
Строгая типизация, нативная поддержка Go
Встроенная поддержка шаблонов
Массовая отправка писем
Webhooks и трекинг доставляемости

Отлично подходит для транзакционных писем, уведомлений и не только. Больше не нужно возиться с настройками SMTP.

Заценить можно тут ❤️

👉 @BackendPortal

freeCodeCamp только что запустили бесплатную интерактивную программу, где можно изучить SQL и реляционные базы данных, а затем получить верифицированный сертификат для LinkedIn.

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

Полный анонс и подробный FAQ здесь

👉 @BackendPortal

Превратите любой репозиторий GitHub в богатую, удобную для навигации документацию.

Просто замените «github» на «deepwiki» в URL-адресе репозитория.

👉 @BackendPortal