⏱️ CRON при репликации сервиса: когда он внезапно запускается дважды

Когда у тебя один инстанс сервиса — cron-задачи живут спокойной жизнью: раз в минуту/час/день отработали — и всё
Но как только появляется горизонтальное масштабирование, начинается цирк: один и тот же cron внезапно запускается на всех репликах

Результат — задвоение задач, дубль-отправки в очередь, лишние запросы в БД, гонки, broken idempotency.
Разбираемся, как это контролировать

🙃 Способы синхронизации CRON между репликами

1) Distributed lock (рекомендуется)

Ты заранее пытаешься взять “маркер лидерства”
Кто взял — тот и выполняет cron. Остальные ждут

Варианты реализации:
— Redis + Redlock
Стандарт: быстрая блокировка с TTL → если под умер, блокировка сама освободится

— PostgreSQL advisory locks
SELECT pg_try_advisory_lock(12345)
Если вернул true, ты — лидер

— PostgreSQL row-level / table-level locks
Простой механизм: лочишь строку “task_name = cleanup_daily”


2) Leader election (лидер выбирается автоматически)

Идея: из всех реплик выбирается одна основная, она и запускает cron.

Варианты:
— Kubernetes leader election через Lease API
Удобно для Cron внутри подов

— Consul / Etcd лидер-электоры
Более enterprise-решение.

3) Cron вынести наружу (лучший вариант для сложных систем)

Перенести все периодические задачи в:
— Kubernetes CronJob
Самый распространённый вариант.
— Airflow / Temporal / BullMQ Scheduler
Если задач много и они взаимосвязаны.
— Dedicated scheduler service

Минус: иногда оверхед для небольших проектов

4) Idempotency + мягкая синхронизация

Если не можешь/не хочешь бороться с параллельностью —
просто проектируешь cron так, чтобы дубликат не ломал логику

Подходы:
— В БД держать processed_at, а cron проверяет “ещё не обработано?”.
— Все действия писать через UPSERT / ON CONFLICT DO NOTHING.
— Слать команды в очередь, где есть idempotency-key.


🚀 Пост Guru Node.js: @DemetraIT

😎 Транзакции в микросервисах: Saga vs 2PC

Когда система разбита на десятки сервисов — классические транзакции через BEGIN/COMMIT уже физически не сработают. Нужны механизмы, которые обеспечат целостность данных между разными сервисами, каждый из которых живёт в своей базе и своём технологическом стеке.

Используют два подхода: Saga и 2PC. Разберём, как они устроены, где применять и какие подводные камни есть у каждого

🌀 Saga Pattern

Saga — это цепочка локальных транзакций, каждая из которых коммитится сразу. Если одна из операций падает — запускаются компенсирующие действия, откатывающие уже выполненные шаги.

Как работает
1. Сервис A создаёт заказ
2. Сервис B списывает деньги
3. Сервис C резервирует товар
4. Сервис D создаёт доставку

Если на шаге 3 ошибка — запускаются компенсации:

— отменить доставку
— снять резерв товара
— вернуть деньги
— отменить заказ

Все шаги асинхронные, с ретраями и идемпотентностью.

Два подхода Saga
1) Orchestration
Есть “дирижёр” (Orchestrator), который знает порядок шагов
Чаще всего — отдельный сервис или компонент (советую почитать про Temporal)

2) Choreography
Сервисы сами реагируют на события друг друга

🔗 Two-Phase Commit (2PC)

2PC — классический дистрибутивный commit: все участники говорят “готов”, после чего координатор говорит “фиксируем”

Как работает
1) Phase 1: Prepare
Координатор опрашивает сервисы:
“Готовы закоммитить транзакцию?”

2) Phase 2: Commit
Если все ответили OK → отправляется COMMIT
Если хотя бы один ответил NO → ROLLBACK

Проблемы 2PC

— блокировки: участники держат транзакции в состоянии prepare
— долгая блокировка ресурсов → падение производительности
— сеть надежна и транзакции будут падать

По факту, 2PC в микросервисах почти не используют — слишком дорог и хрупок

🐗 Вывод юзаем сагу

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

🚀 Пост Guru Node.js: @DemetraIT

🔍 Инструменты чтения плана запроса: EXPLAIN и EXPLAIN ANALYZE

Когда запрос в базе работает медленно — не надо гадать на кофейной гуще. В PostgreSQL есть два супер-инструмента, которые позволяют увидеть, что именно делает оптимизатор и где запрос тратит время

Речь про EXPLAIN и EXPLAIN ANALYZE

🥰 EXPLAIN — прогноз плана

EXPLAIN показывает, как PostgreSQL собирается выполнить запрос:
— какие индексы может использовать
— какой тип сканирования выберет (Seq Scan, Index Scan, Bitmap Index Scan)
— предполагаемое количество строк
— стоимость выполнения (cost)

😁 Полезно, когда ты хочешь понять теоретический план без реального запуска запроса

Пример запроса

EXPLAIN SELECT * FROM users WHERE email = 'test@mail.com';

⸻

⚡️ EXPLAIN ANALYZE — фактические замеры

EXPLAIN ANALYZE выполняет запрос реально и показывает:
— сколько времени занял каждый шаг
— реальное количество строк
— время старта операции
— расхождение между прогнозами и фактами

Если EXPLAIN — теория, то EXPLAIN ANALYZE — практика

Пример запроса

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@mail.com';

📝 Тут внимательнее: запрос действительно выполнится, поэтому с UPDATE/DELETE используй на тестовых данных

⸻

😴 Что смотреть в плане?
1) Seq Scan — сигнал: возможно нет индекса
2) Row Estimate vs Actual Rows — если сильно расходится, оптимизатор ошибся → можно помочь статистикой
3) Filter / Recheck — где происходит фильтрация
4) Timing — какой узел съедает больше всего времени
5) Planning Time / Execution Time — понять, где узкое место

🚀 Пост Guru Node.js: @DemetraIT

📝 CAP-теорема простыми словами

Иногда на собесах или работе можно встретить вопрос про CAP теорему

В распределённых системах нельзя одновременно обеспечить три свойства:
1) C — Consistency: все узлы возвращают одинаковые данные
2) A — Availability: система всегда отвечает (не важно ошибки в бд или успех)
3) P — Partition tolerance: работает даже при проблемах сети при масштабировании

Причем в реальности выбираем P неизбежно, так как сеть ненадежна.
Поэтому реальный выбор — между C и A

☺️ CP — согласованность важнее доступности

Система лучше не ответит, чем вернёт разные данные из разных узлов
Примеры: Zookeeper, etcd, PostgreSQL в синхроне

💀 AP — доступность важнее согласованности

Система отвечает всегда, даже если данные временно расходятся. Это может быть удобно, например, при реализации лайков (не страшно, если будет расхождение)
Примеры: Cassandra, MongoDB, Dynamo-подобные

💡 Итог
CAP — это про компромисс: что для тебя важнее при аварии — доступность или корректность данных?

Есть еще так NewSQL, которые якобы могут и масштабироваться, советую почитать про такой вид бд

🚀 Пост Guru Node.js: @DemetraIT