sequenceDiagram
autonumber
box "Продюсеры событий" #f9f9f9
participant Mobile as Mobile App (VTT)
participant Engine as Sim Engine
end
box "Брокер сообщений" #eeeeee
participant Kafka as Kafka: inventory-stream
end
box "Консьюмер событий" #e1f5fe
participant IS as Inventory Service (Consumer)
participant DB as Postgre (State DB)
participant Logs as Error Logger
end
Note over Mobile, Engine: Шаг 1: Генерация событий
Mobile->>Kafka: voice_to_json("Добавить 5 молока")
Engine->>Kafka: auto_replenish(user_id)
Note over Kafka, IS: Шаг 2: Непрерывное потребление
loop Опрос событий (Polling)
Kafka->>IS: Получение пачки сообщений
rect rgb(240, 240, 240)
Note right of IS: Шаг 3: Транзакционная запись
IS->>DB: INSERT/UPDATE fact_inventory
alt База данных доступна
DB-->>IS: 200 OK
IS->>Kafka: Фиксация смещения (Commit Offset)
else Ошибка базы данных
IS->>Logs: Запись в fact_error_logs (SQL Error + Raw Payload)
Note right of IS: Сообщение остается в Kafka для повтора
end
end
end
Сервис Inventory
Сервис работы с ‘цифровым холодильником’ как с неким бизнес-процессом
1. Шаблон Kafka-Consumer с интеграцией Voice-to-Text: Асинхронная запись
В этой модели (Inventory Service) работает как выделенный Подписчик (Subscriber) на топик Kafka inventory-updates. Этот подход «выстрелил и забыл» (Fire and Forget) позволяет мобильному приложению и движку симуляции мгновенно отправлять данные, в то время как сервис обрабатывает записи в PostgreSQL в своем темпе.
2. Диаграмма последовательности: От записи голоса к записи в базе данных
В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.
На схеме показано, как голосовая команда транскрибируется, ставится в очередь Kafka и в конечном итоге сохраняется в базе данных консьюмером.
3. Примеры JSON-пакетов Kafka
В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.
Ниже представлены стандартизированные схемы JSON, которые ожидает получить Inventory Service.
Голос-в-Текст (VTT)
{
"event_id": "vtt-789-xyz",
"source": "mobile_web_vtt",
"user_id": 123,
"timestamp": "2023-10-27T10:00:00Z",
"action": "ADD_INVENTORY",
"data": {
"item_name": "Молоко",
"quantity": 5,
"unit": "пакет",
"raw_transcript": "Я добавил пять пакетов молока"
}
}Движок симулятора
{
"event_id": "sim-456-abc",
"source": "sim_engine_v3",
"user_id": 123,
"timestamp": "2023-10-27T10:00:01Z",
"action": "AUTO_REPLENISH",
"data": {
"trigger": "p_visit_0.85",
"strategy": "full_restock",
"inventory_delta": "calculate_on_consume"
}
}4. Логика реализации: работа консьюмера
Логика Inventory Service следует паттерну отказоустойчивой обработки:
- Poll: Извлечение следующей пачки сообщений из топика
inventory-stream. - Validate: Проверка структуры JSON и валидности
user_idилиsim_id. - Execute: Преобразование JSON-команды в SQL Prepared Statement.
- Audit: Если SQL-запрос не удался, логгирование
raw_payloadв таблицуfact_error_logs. Это позволяет вручную восстановить данные или отладить ошибки распознавания голоса.
5. Заключение
Архитектура полностью отделяет Интерфейс пользователя (Mobile App) от Уровня данных (Postgres). Использование Kafka в качестве посредника делает систему горизонтально масштабируемой и устойчивой к простоям базы данных.
Мы внедрим Schema Registry, чтобы гарантировать, что любые изменения в формате JSON на стороне мобильного приложения не нарушат логику работы консьюмера.