Как мы «строили» систему диспетчеризации в карьере.

Сегодня поделюсь текущим кейсом, который можно было избежать, но, как говорится «опыт - сын ошибок трудных…». Работаем над системой диспетчеризации для горного транспорта в карьере. В какой-то момент начали замечать: 📉 сообщения от водителей долго доходят до диспетчера 📉 команды диспетчера тоже не всегда вовремя прилетают обратно

А теперь внимание — у нас была такая схема:

• Телеметрия (где техника, как работает) летит с машины по MQTT → Kafka → сервер — всё ок, быстро. • А вот сообщения от водителя с планшета и команды диспетчера — через HTTP. И вот тут начались задержки, особенно когда связь в карьере не очень.

Решили упростить: убрали HTTP и перевели всё на единую “шину” MQTT + Kafka.

Что ожидаем:

1. Машина публикует в топики MQTT и телеметрию, и сообщения от водителя. 2. Kafka их забирает и передаёт на сервер. 3. Сервер обрабатывает и публикует обратно — через Kafka → MQTT → машина.

Что получаем: ✅ скорость выше ✅ схема проще — один канал вместо двух ✅ можно развивать дальше: техника сможет “общаться” между собой напрямую (P2P), например, предупреждать о пробке на отвале

В итоге делаем топики по каждому типу сообщений, настроили QoS (важные команды гарантированно доходят) и готовимся обкатывать всё это на тестовом участке.

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

Иногда решение — просто убрать лишнее.

А можно сразу сделать хорошо.🤓