# Демо-пайплайн: IoT → SQS → Fission

## Архитектура

1. **Крон-функция (Fission)**
   - Парсит данные о погоде с сайта для нескольких городов
   - Эмулирует IoT-датчики: отправляет данные в IoT-сервис (MQTT/HTTP)

2. **IoT-сервис**
   - Принимает данные от "датчиков"
   - Публикует сообщения в очередь (SQS или аналог)

3. **Очередь (SQS)**
   - Хранит сообщения от IoT
   - Триггерит Fission-функцию при появлении новых данных (MessageQueue Trigger)

4. **Fission-функция**
   - Получает данные из очереди
   - Записывает их в таблицу (PostgreSQL, ClickHouse и т.д.)

## Требования к Fission

- Необходим MQ-триггер (MessageQueue Trigger) для автоматического запуска функции по сообщениям из очереди.
- Сейчас в Fission есть HTTP, Cron, Event, но нет универсального MQ-триггера.
- Возможные варианты:
  - Реализовать внешний watcher (SQS/Kafka/RabbitMQ → invoke HTTP endpoint Fission)
  - Добавить поддержку MQ-триггера в сам Fission (новый CRD + контроллер)

## Примечания

- Все компоненты связаны через API/очереди, каждый слой изолирован.
- Такой пайплайн типовой для облачных платформ и легко масштабируется.
- Для MVP достаточно watcher-а очереди, который вызывает функцию через HTTP.

---

Если потребуется — расписать детальный план интеграции или примеры кода для каждого этапа.