Kafka в Застрахователни Системи: Архитектура за Висока Конкурентност

Когато една застрахователна компания трябва да обработва голям обем ежедневни транзакции — записвания, директни дебити, проверки спрямо рискови списъци, токенизация на карти —, синхронният модел заявка–отговор става крехък, щом критична операция зависи от няколко интеграции с различно забавяне; при пикове това свързване увеличава времето за изчакване, ако няма ограничения и контролирана деградация.

Същинският проблем: времевото свързване

В традиционна синхронна система времето, необходимо на услугата за токенизация на карти, се добавя към общото време за отговор на транзакцията. Ако проверката спрямо вътрешни рискови списъци, списъци на блокирани лица и източници на санкции —всеки със своя честота на актуализация, консултирана версия и доказателство— е под натоварване, цялата верига чака. Резултатът е предвидим: изтичане на времето (timeouts), ръчни повторни опити и грешки при съгласуване.

Apache Kafka решава това с принципно различен модел: вместо услугите да се извикват взаимно, те публикуват събития в топици (topics), а всеки потребител ги обработва независимо, със собствен ритъм. Kafka може да предложи обработка exactly-once в добре конфигурирани потоци на Kafka; когато участват API, платежни процесори или външни бази данни, остават необходими идемпотентни идентификатори, обработка на дубликати и съгласуване (например с шаблона outbox).

Как записването се решава със събития

Обичайният модел в застрахователните платформи е следният: началото на записването се публикува като събитие, а проверките —на самоличност, ограничителни списъци, токенизация на платежното средство— се обработват от независими потребители, които публикуват резултата си. Координацията следва шаблона saga – чрез хореография (всяка услуга реагира на събитията на останалите) или чрез оркестрация (един компонент събира резултатите и решава дали записването продължава). Стойността не е в обмена на съобщения, а в това проверките да не се блокират взаимно.

Записването се моделира като машина на състоянията —изчакващо, в проверка, одобрено, отхвърлено, изтекло, в преглед— и се определя какво се случва при дублирани или закъснели резултати, недостъпност на трета страна и изтичане на срокове.

Оперативната разлика е по естество, а не по степен. Пикът на търсенето престава веднага да се превръща в timeouts: опашката поема обема, а всеки потребител обработва със собствен ритъм. Плаща се със забавяне при обработката. Разделянето намалява разпространението на откази, но не премахва риска: необходими са ограничения на потреблението, ограничени повторни опити, опашки за изключения и наблюдение на изоставането.

Проследимостта като изискване от първостепенно значение

Едно от най-строгите изисквания в застрахователния сектор е одитът. Всяка транзакция — от първоначалната заявка до потвърждението на плащането — трябва да може да се проследи с времеви печати, междинни състояния и идентичност на системата, обработила всяка стъпка. Събитията са ценен източник на доказателства, но не заместват одитна пътека: трябва да се определят одитируеми събития, корелация, времеви печат, цялост, съхранение и хранилище, което може да се запитва, отделно от задържането в Kafka.

Топиците не бива да разпространяват чувствителни данни: публикуват се препратки или псевдонимизирани идентификатори и минимумът необходими данни; криптиране при пренос и в покой, достъп по топик и определено съхранение. Данните от картите остават извън платформата за събития, според модела на отговорност на PCI DSS; пренася се токенът.

Съображения за продукционна среда

Kafka не е безплатен откъм оперативна сложност. Изисква правилно определяне на броя на партициите (влияе върху максималния паралелизъм), на фактора на репликация (влияе върху устойчивостта), на съхранението на съобщенията (влияе върху разходите за хранилище) и на политиките за идемпотентност на потребителите (влияе върху консистентността). В среди с Kubernetes специализиран оператор значително опростява жизнения цикъл на клъстера.

Практическото правило, което се потвърждава в употреба, е следното: Kafka е правилният избор, когато има няколко независими потребители, които се нуждаят от едно и също събитие, когато е необходимо повторно възпроизвеждане (replay) на събития за отстраняване на грешки или миграция и когато наличността на производителя не може да зависи от наличността на потребителя. За комуникация заявка–отговор между две услуги, които се нуждаят от незабавен отговор, синхронният REST остава по-прост и подходящ.