Короткий ответ
Сначала превращаю запрос «нужна база» в проверяемые требования: тип данных и движок, объём и рост, пиковая нагрузка, окружения, доступность, RPO/RTO, backup, безопасность, владелец, срок и бюджет.
Как это работает подробнее
Одинаковая формулировка может означать небольшой PostgreSQL для MVP или критичный кластер с репликами и строгим восстановлением. Без уточнений инженер либо переплатит за запас, либо создаст конфигурацию, которая не выдержит production.
- Нагрузка. Оценить RPS, число соединений, характер чтения и записи, объём сейчас и прогноз роста.
- Надёжность. Согласовать допустимый простой, потерю данных, частоту backup и проверку восстановления.
- Эксплуатация. Определить окружения, владельца данных, доступы, мониторинг, срок и бюджет.
Что использовать на практике
- Чек-лист. Зафиксировать ответы в тикете и получить подтверждение команды разработки и владельца сервиса.
- Проверка. Сопоставить требования с классом инстанса, хранилищем, репликацией и прогнозной стоимостью.
- Минимальный старт. Для MVP выбрать достаточную конфигурацию и заранее описать сигналы для масштабирования.
Подводные камни
- Частая ошибка. Копировать конфигурацию другого сервиса без сравнения профиля нагрузки и критичности.
- Потерянное требование. Обсудить технологии, но забыть про бюджет, срок, владельца и проверяемое восстановление.