Сервис Inventory

Сервис работы с ‘цифровым холодильником’ как с неким бизнес-процессом

Автор

Research Framework

Дата публикации

11 июня 2026 г.

1. Шаблон Kafka-Consumer с интеграцией Voice-to-Text: Асинхронная запись

В этой модели (Inventory Service) работает как выделенный Подписчик (Subscriber) на топик Kafka inventory-updates. Этот подход «выстрелил и забыл» (Fire and Forget) позволяет мобильному приложению и движку симуляции мгновенно отправлять данные, в то время как сервис обрабатывает записи в PostgreSQL в своем темпе.

2. Диаграмма последовательности: От записи голоса к записи в базе данных

ПредупреждениеВажное примечание

В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.

На схеме показано, как голосовая команда транскрибируется, ставится в очередь Kafka и в конечном итоге сохраняется в базе данных консьюмером.

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

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 следует паттерну отказоустойчивой обработки:

  1. Poll: Извлечение следующей пачки сообщений из топика inventory-stream.
  2. Validate: Проверка структуры JSON и валидности user_id или sim_id.
  3. Execute: Преобразование JSON-команды в SQL Prepared Statement.
  4. Audit: Если SQL-запрос не удался, логгирование raw_payload в таблицу fact_error_logs. Это позволяет вручную восстановить данные или отладить ошибки распознавания голоса.

Правило восстановления Kafka Если Inventory Service упадет, Kafka запомнит последнее обработанное сообщение (смещение/offset). После перезапуска сервис продолжит работу ровно с того места, где остановился, гарантируя нулевую потерю данных.


5. Заключение

Архитектура полностью отделяет Интерфейс пользователя (Mobile App) от Уровня данных (Postgres). Использование Kafka в качестве посредника делает систему горизонтально масштабируемой и устойчивой к простоям базы данных.

СоветЧто дальше?

Мы внедрим Schema Registry, чтобы гарантировать, что любые изменения в формате JSON на стороне мобильного приложения не нарушат логику работы консьюмера.