Эти сценарии помогают быстро показать ценность симулятора разным аудиториям: архитекторам, инженерным командам, преподавателям, студентам и product/CTO. Это не benchmark и не обещание поведения production-системы, а безопасная песочница для обсуждения trade-off-ов.
Microservices
API → broker → consumer → PostgreSQL
Базовый поток для объяснения, зачем нужна очередь между sync API и тяжёлой записью. Меняйте входящую нагрузку, число consumers и задержку базы, чтобы увидеть рост backlog и p99.
- Показать разницу между sync-вызовом и асинхронной обработкой.
- Обсудить, где появляются bottlenecks: API, broker, consumer или storage.
- Зафиксировать, какие метрики стоит проверить уже в реальной системе.
Reliability
Отказ consumer и восстановление очереди
Сценарий для разговора об отказоустойчивости: один компонент временно перестаёт обрабатывать сообщения, очередь растёт, затем система догоняет накопленный поток.
- Проверить, насколько быстро backlog возвращается к норме.
- Обсудить retry, dead-letter queue и degradation mode без углубления в vendor-specific детали.
- Показать, почему средняя latency скрывает проблему лучше, чем p99.
Kubernetes
Capacity planning для Kubernetes-style сервиса
Используйте Kubernetes-style узлы, upstream API и БД, чтобы объяснить связь между replicas, лимитами, bottleneck у зависимости и итоговым throughput.
- Сравнить масштабирование приложения и ограничения downstream-сервиса.
- Показать, что больше replicas не всегда означает больше throughput.
- Связать архитектурную диаграмму с привычными observability-метриками.
Architecture review
Интерактивный RFC вместо статичной схемы
Команда собирает предполагаемую архитектуру на холсте и использует симуляцию как повестку review: какие допущения есть, где нужны реальные замеры, какие решения пока рискованны.
- Сделать спорные assumptions явными для всех участников.
- Разделить учебную симуляцию и обязательную production-валидацию.
- Сформировать список вопросов для follow-up экспериментов.