Проектирование бэкенда

При cache-aside приложение смотрит в кеш и при промахе само читает из базы и кладёт значение в кеш. При write-through каждая запись идёт через кеш, который синхронно обновляет базу, поэтому они не расходятся. Вытеснение по TTL выбрасывает запись по истечении фиксированного времени жизни, ограничивая устаревание значения.

timeout ограничивает, сколько ждать медленный вызов, чтобы поток не блокировался вечно. retry повторяет вызов, упавший по временной причине (сетевой сбой, 503), восстанавливаясь незаметно. circuit breaker перестаёт звать уже падающий downstream — после достаточного числа ошибок он размыкается и быстро отклоняет вызовы, пока зависимость не восстановится.

Оберните вызов цен breaker'ом: он считает ошибки и медленные вызовы в скользящем окне и размыкается, когда их доля переходит порог — таймаут обязан считаться, ведь инцидент был про задержку. Пока он разомкнут, вызов мгновенно падает в fallback с кешированной или дефолтной ценой, и поток не паркуется. После паузы он полуразмыкается, пробует пару вызовов и замыкается, только если они прошли.

Держите счётчики в хранилище, общем для всех инстансов, например в Redis, чтобы лимит был на весь флот, а не на узел, и пропускайте вызовы по token bucket — ровная скорость пополнения плюс глубина ведра, впитывающая короткий всплеск. Клиенту сверх лимита отвечайте 429 Too Many Requests с заголовком Retry-After. Вызов в хранилище оберните жёстким таймаутом и падайте открытым.

Браузер → checkout остаётся REST: он публичный, кешируемый, отлаживаемый, и его уже понимает любой клиент. checkout → pricing — горячий внутренний вызов между двумя Java-сервисами, поэтому выигрывает gRPC: компактный бинарный payload и сгенерированный контракт. invoicing асинхронен по природе — публикуйте событие в брокер, тогда заказ завершается, пока invoicing лежит.

По SIGTERM заваливайте readiness-пробу, продолжая обслуживать: балансировщик выводит под из ротации, а запросы в полёте дорабатывают. Только потом переставайте принимать соединения и дайте серверу слиться в пределах таймаута. Исполнителей гасите через shutdown() и awaitTermination, чтобы пачка доделалась или вернулась. Все ожидания ограничены, чтобы слив уложился в grace-период.

Ключуйте событие устойчивым бизнес-идентификатором — id платежа, а не offset — и пишите этот ключ в таблицу обработанных событий в той же транзакции, что и строку проводки. Уникальное ограничение делает повтор no-op, а транзакция не даёт падению записать одно без другого. Письмо уходит через outbox, дедуплицирующий по тому же ключу.

Caffeine держит горячие ключи на каждой JVM под коротким TTL, Redis — общий уровень за ним, и только промах в обоих идёт в базу. На запись вытесняйте ключ в Redis и публикуйте его, чтобы двенадцать инстансов сбросили локальную копию за секунду; локальный TTL — лишь подстраховка. Одновременные промахи по ключу схлопывайте в одну загрузку, а при недоступном Redis падайте открытым за breaker'ом.