Чи є ваш масштабований бекенд бомбою сповільненої дії?

Багато розробників вважають, що масштабування означає додавання нових серверів. Вони використовують cloud-native інструменти та розподілені бази даних, щоб обслуговувати більше користувачів. Але це часто створює нову проблему. Ви будуєте не фортецю. Ви будуєте картковий будинок.

Горизонтальне масштабування без плану лише розширює ваші зони відмови (failure domains). Якщо вашій системі бракує відмовостійкості, одна невелика помилка може призвести до краху всього.

Щоб побудувати справді надійну систему, ви повинні зосередитися на двох аспектах:

  1. Відмовостійкість (Fault Tolerance) Додавання більшої кількості екземплярів не запобігає корельованим збоям. Ви повинні ізолювати помилки, щоб вони не поширювалися.
  • Використовуйте кілька зон доступності (Availability Zones).
  • Використовуйте багато малих екземплярів сервісу замість двох великих.
  • Використовуйте консенсус на основі кворуму, такий як Raft або Paxos. Це запобігає сценаріям split-brain, коли два регіони вважають себе лідерами.
  • Використовуйте механізми fencing, щоб вимикати несправні регіони під час розриву мережі.
  1. Узгодженість даних (Data Consistency) Послідовна узгодженість (eventual consistency) чудова для швидкості. Але вона жахлива для критичної бізнес-логіки. Для платежів або балансів рахунків вам потрібна сувора узгодженість (strong consistency).
  • Не покладайтеся на розподілені транзакції, які уповільнюють вашу систему.
  • Використовуйте патерн Transactional Outbox.
  • Записуйте основні дані та завдання "outbox" у свою локальну базу даних однією транзакцією.
  • Використовуйте релей (relayer) для відправки цих завдань у чергу повідомлень.
  • Переконайтеся, що ваші downstream-сервіси є ідемпотентними, щоб вони могли безпечно обробляти дублікати повідомлень.

Справжня масштабованість — це стійкість. Якщо ви ігноруєте ці принципи, ви просто створюєте більший майданчик для збоїв. Проектуйте систему з урахуванням найгіршого сценарію вже сьогодні.

Джерело: https://dev.to/prabashanadev/is-your-scalable-backend-a-ticking-time-bomb-6o7