Lexora

Задача

Продукт, де одна дія користувача має запустити кілька наслідків нижче за течією, і жоден із них не має права тихо не статися. Наївний варіант, коли побічні ефекти виконуються всередині запиту, втрачає роботу щоразу, коли щось падає на півдорозі.

Система

Бекенд на Rust навколо подієвого ядра. Зміна стану та події, які вона породжує, фіксуються разом через transactional outbox, а фонові воркери забирають ці події й виконують повільну роботу поза запитом. Зверху фронтенд на React, і все це працює на Cloud Run.

Моя роль

Архітектура бекенду й реалізація подієвого ядра, дизайн outbox і воркерів, а також операційна історія в проді.

Найскладніше

Гарантії доставки. Між записом у базу й повідомленням решти системи є вікно, у якому падіння губить подію. Закрити це вікно без розподіленої транзакції — це фактично весь дизайн.

Архітектурні рішення

1. Доставка щонайменше один раз з ідемпотентними споживачами. Дублікати обходяться значно дешевше за втрати, тому воркери написані так, щоб спокійно бачити одну подію двічі.
2. Черга — це PostgreSQL. Kafka додала б цілий операційний шар і другий домен відмов, про який треба думати, і все одно потребувала б outbox, щоб бути атомарною з транзакцією, яку описує, — тож у цій системі брокер не дає нічого, чого вже не дає таблиця. LISTEN/NOTIFY відхилено як основний механізм із простішої причини: сповіщення ніде не зберігаються, тож воркер, який лежить, пропускає їх повністю.
3. Узгодженість із часом стосується лише побічних ефектів. Авторизація, збереження призначень і стан навчання лишаються синхронними, тож учневі ніколи не показують розклад, який не зафіксовано надійно. Витрати на чергу прийняті, а не приховані: опитування додає близько двох секунд затримки, коли система простоює, а таблиця outbox росте, доки не з'явиться завдання очищення.

Поточний стан

У проді. Red Sentra продовжує супроводжувати й розвивати його.