Срезали p95 API под пиковую нагрузку
PropTech · vacation rental SaaSGuestyСпринт2025

Срезали p95 API под пиковую нагрузку

p95 820ms → 180ms

Guesty — AI PMS для short-term rental: realtime-синк листингов и тарифов по 70+ каналам (Airbnb, Booking.com, Vrbo…). Под пиками бронирований p95 горячего API уезжал, интеграции ловили таймауты. За два спринта вернули предсказуемый SLA.

820ms → 180msp95 latency
−100% (окно 14 дн.)Таймауты на пике
2 спринтаСрок

// проблема

Что ломалось

Вечерние и сезонные пики: p95 API уходил за ~800ms, часть channel/booking-интеграций отваливалась по таймауту. Горячий путь обрабатывался синхронно, без бэкпрешера и нормальных RED-метрик — оптимизировать было не на чем, кроме ощущений.

// решения

Что сделали

  1. Вынесли горячий путь (синк availability / rates / reservations) в отдельный воркер с очередью и лимитом параллелизма.
  2. Повесили RED-метрики и алерты по p95 / error rate до любых «оптимизаций наугад».
  3. Контракт внешнего API оставили без breaking changes — партнёры и Open API клиенты не трогали.

// результат

Чем закончилось

За две недели p95 на горячем эндпоинте упал с ~820ms до ~180ms при том же железе. Таймауты интеграций на пике исчезли в наблюдаемом окне; realtime-синк каналов снова предсказуем.

GoPostgresKafkaGrafanaKubernetes