Масштабування після MVP: архітектурні рішення, які мають значення
Платформа в перший день не потрібна. Потрібні кілька рішень, які не заженуть вас у пастку на шостому місяці.
/ Зміст:
Нехай MVP буде навмисно нудним
Моноліт з ясними модулями, одна база і нудний хостинг пронесуть більшість продуктів далі за діаграму мікросервісів. Діліть сервіси, коли команда або вузьке місце змушують — не тому що так написали в блозі. Передчасний розподіл — це розподілена плутанина.
Паніка «треба все переписати» зазвичай про відкладену модель даних, а не про фреймворк.
/ Dimitriy Caliber
Рішення, які важливі рано
Назвіть ключові сутності й ID так, ніби вони залишаться. Відділіть auth від бізнес-даних. Логуйте достатньо, щоб розібрати невдалий платіж. Файли й секрети — у правильному місці. На другому тижні це дешево, після реальних клієнтів — дорого.
- Одне джерело правди для користувачів і ролей
- Міграції, які можна запустити, а не усні знання
- Середовища: local, staging, production
Коли справді масштабувати
Масштабуйте, коли болить метрика: повільні запити, черга, деплой, якого всі бояться. Потім профілюйте. Часто ліки — індекс, кеш або винести важку роботу з запиту. Kubernetes цю розмову не замінює.
Залиште двері відчиненими
Зробіть інтерфейси навколо платежів, пошти й одного вендора, якого можете замінити. Не абстрагуйте все. Абстрагуйте два-три місця, де заміна інакше означала б перепис. Це архітектура як страховка, не як декор.
Є проєкт на думці?
Залиште ім'я та зручний контакт. Ми повернемося з наступним кроком.