Современная архитектура обычно предполагает поднимать для масштабирования много экземпляров одного сервиса с асинхронным взаимодействием через сообщения. При этом есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. Многие из этих аспектов проявляются при работе пользователя, который получает непредвиденные ошибки и неустойчивую работу системы, влияют на стоимость инфраструктуры и работу службы поддержки. Поэтому возможные решения надо обсуждать не только между разработчиками, а со всеми участниками проекта, включая бизнес.

Для этого хорошо иметь наглядное визуальное представление, которое послужит основой для обсуждения. Классические подходы и диаграммы проектирования — ER-диаграммы, UML и другие — были придуманы в эпоху монолитов, не слишком хорошо позволяют обсуждать такую архитектуру.

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