Back to Back

В докладе рассматривается расширение PostgreSQL PGMQ, его применение в AI-конвейерах на Python и способы использования гарантии доставки сообщений «ровно один раз» (exactly-once) для построения надежных и отказоустойчивых систем обработки данных.

Журнал предзаписи PostgreSQL (Write-Ahead Log, WAL) — это, по сути, журнал изменений базы данных. Именно он лежит в основе ряда ключевых возможностей PostgreSQL, включая восстановление после сбоев, восстановление на определенный момент времени (Point-in-Time Recovery, PITR), а также физическую и логическую репликацию.

В докладе будет рассмотрено, какие данные хранятся в WAL, как работают физическая и логическая репликация и каким образом слоты репликации (replication slots) позволяют отслеживать прогресс репликации.

Современным распределенным системам нужны идентификаторы, которые обеспечивают уникальность, масштабируемость, эффективность и во многих случаях возможность сортировки. В этом докладе Монс Андерсон, Solution Architect в Exness, проследит эволюцию алгоритмов генерации идентификаторов — от автоинкрементных значений в базах данных и UUID до Snowflake, KSUID, NanoID, ULID и других современных схем.

В докладе будут сравнены различные подходы с точки зрения гарантии уникальности, возможности сортировки, эффективности хранения, читаемости, сложности эксплуатации и пригодности для использования в распределенных системах. Особое внимание будет уделено UUID v7, который вобрал в себя опыт предыдущих поколений и постепенно становится новым отраслевым стандартом.

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

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

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

В докладе разберём, почему fail-open — это прежде всего бизнес-решение, чем могут отличаться одинаковые ответы ALLOW, как запасные сценарии влияют на уровень доверия к проверке и какие новые риски создают Circuit Breaker, таймауты и другие защитные механизмы.

На реальных примерах покажу, почему в антифроде цена таких ошибок — не только отказ сервиса, но и пропущенные мошенники или заблокированные добросовестные пользователи.