Почему скучные решения стали моими лучшими решениями

Раньше я думал, что быть хорошим разработчиком — значит писать сложный код.

Я ошибался.

Проектируя MVP для медицинской клиники, которая со временем должна превратиться в multi-tenant SaaS, я усвоил тяжелый урок. Код — это самая простая часть. Самое сложное — решить, что НЕ нужно строить.

Возникало искушение использовать микросервисы, события и Kubernetes. Это отлично смотрится в резюме. Но у микросервисов высокая цена. Вы платите за них сложными пайплайнами, проблемами версионирования и трудностями при отладке.

При команде из трех человек и небольшом количестве пользователей микросервисы — это просто лишняя работа. Вы решаете проблемы, которых у вас еще нет.

Вместо этого я выбрал простую многослойную архитектуру на .NET 8 и PostgreSQL. Это обходится примерно в $30 в месяц.

Я сосредоточился на умных и дешевых решениях, которые будет дорого менять позже:

• Добавил колонку TenantId в каждую таблицу с первого же дня. • Использовал Docker с первого коммита. • Создал интерфейс для провайдера WhatsApp.

На каждое из этих решений ушел всего один вечер. Они превратили будущие миграции в простые изменения конфигурации.

Я также научился подбирать паттерны в соответствии с потребностями бизнеса.

Например, я использовал паттерн Outbox для уведомлений WhatsApp. Запись на прием должна быть быстрой и надежной. Отправка сообщения может произойти на пару секунд позже. Если WhatsApp будет тормозить, запись все равно будет оформлена.

Однако я отказался от «согласованности в конечном счете» (eventual consistency) для медицинских записей. Медицинский диагноз должен быть точным и мгновенным. В здравоохранении юридические требования фактически являются архитектурными требованиями.

Я также посмотрел на реальные цифры.

Настройка Kubernetes (EKS) стоила бы от $545 до $615 в месяц. Настройка AWS Fargate стоит от $350 до $420 в месяц.

Это экономия более $150 каждый месяц. Я выбрал Fargate, потому что это проще и дешевле при наших текущих масштабах.

Моя стратегия проста:

  1. Сначала используйте слои (layers).
  2. Используйте события, когда внешние зависимости (такие как WhatsApp) начинают влиять на вашу систему.
  3. Переходите на микросервисы только тогда, когда этого потребуют объемы и размер команды.

Не проектируйте систему под двадцать клиентов, которых у вас еще нет. Стройте для того клиента, который платит вам сегодня.

Источник: https://dev.to/jose_confalonieri_3891172/lo-que-aprendi-disenando-un-saas-para-clinicas-por-que-la-decision-mas-importante-fue-la-mas-4iom