Redis distributed lock не защищает деньги. Вообще
С подобными проблемами я сталкиваюсь в каждом втором проекте. Проектирую и чиню backend-системы, где цена ошибки это реальные деньги: fintech, crypto, e-com, логистика. Вот несколько примеров из практики. Криптоплатформа, 50–500k пользователей в пике. Двойные зачисления из-за отсутствия идемпотентности. Внедрили идемпотентные ключи и SELECT FOR UPDATE NOWAIT на балансах. Результат: 8 месяцев в проде без единого дублирующего зачисления, throughput вырос в 4 раза, webhook доставка 100%. Монолит с 30-секундными отчётами. Тормоза и блокировки в рабочее время. Переписали архитектуру до 1.5с без даунтайма. PDF счета с расхождениями в суммах. После внедрения транзакционной изоляции 100% точность за 12 месяцев. Специализация: системы, где нельзя терять транзакции и данные при сбоях. Стек: FastAPI, Django, PostgreSQL, Celery, Redis, Docker, WebSocket. Больше кейсов с архитектурными решениями и цифрами на сайте goldin-systems.ru. #fintech #crypto #backend #python #fastapi #postgresql #архитектура #highload #микросервисы #celery
· 26.04
согласен, это классическая ловушка. Redis lock даёт иллюзию атомарности, но гарантии нет - процесс может умереть после lock acquire и до commit. использую Celery + Redis в паре проектов, для критичных финансовых операций перешёл на db-level advisory locks в PostgreSQL. для подготовки к таким вопросам на собесах помогает jobpath.world - там как раз разбираются кейсы про distributed systems и concurrency
ответить
коммент удалён