⚙️ Подробный разбор этапов: сервис стримингого обогащения.

Начинаем с него, так как это самый "слабый" участок нашей архитектуры.

Расчеты:
1 сообщений млрд в сутки = ~11500 сообщений в секунду.
1 CPU способен обработать примерно 1000 таких операций в секунду (цифра взята из опыта работы с подобными задачами).
12 CPU = 100% нагрузки, что влечет риски отказов при неравномерной нагрузке.

Внедрим горизонтальную масштабируемость:
1 под сервиса - 4 CPU;
3 пода — 12 CPU = 100% нагрузки;
6 подов — 24 CPU = 50% нагрузки. Это будет количество подов по умолчанию. Есть запас для обработки пиков, при неравномерной нагрузке.

На случай непредвиденного роста сообщений добавим HPA этому сервису со значением 6-12.

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

❓Почему RAM (оперативная память) не будет оказывать сильного влияния на производительность?

Сообщения имеют небольшой размер — в среднем 2кб, поэтому для обработки такого потока сообщений нам будет достаточно 2GB оперативной памяти.

Пример для этого случая:

✅CPU — это скорость движения конвейерной ленты и количество рабочих. Если рабочих мало или лента медленная — бутылочное горлышко.

❌RAM — это размер стола каждого рабочего. Если стол слишком маленький, рабочий не сможет разложить инструменты и детали, работа встанет. Но как только стол достиг достаточного размера, его дальнейшее увеличение не ускорит работу рабочего.

Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин