Введение: эволюция программного принятия решений

Когда в пятницу вечером маркетинг просит срочно изменить порог для бесплатной доставки, а у вас в коде зарыт десяток переплетенных if-else в трех разных микросервисах — это не просто стресс, это архитектурный тупик (причём заботливо выстроенный вашими предшественниками года два назад). Современные распределенные системы требуют от разработчиков не просто хранения и обработки терабайт данных, но и их оперативного осмысления. Исторически бизнес-логика жестко кодировалась внутри монолитов или распылялась по десяткам сервисов, создавая высокую связанность кода и катастрофически замедляя Time-to-Market.

Концепция Decisions-as-a-Service (DaaS) призвана разорвать этот порочный круг. Выход Decisions API в публичную бету знаменует стандартизацию подхода к управлению программной логикой, избавляя инженеров от необходимости внедрять громоздкие движки BRMS (Business Rule Management Systems) или писать собственные DSL-интерпретаторы.

Что такое Decisions API и какую архитектурную боль он снимает?

Представьте интернет-магазин в Черную пятницу: правила начисления бонусов, антифрод и динамические скидки меняются каждые полчаса. Пересобирать и деплоить бэкенд под каждый чих бизнеса больше не нужно — на помощь приходит Decisions API.

Decisions API — это выделенный программный интерфейс, инкапсулирующий логику принятия решений вне кода основного приложения. Вместо лабиринтов из if-else и switch-case бэкенд отправляет структурированный JSON-пейлоуд на эндпоинт API, а взамен получает детерминированный вердикт (и надежду, что сеть до дата-центра сегодня не решит отдохнуть).

Главный дивиденд от внедрения такого подхода — реальное разделение ответственности между разработкой и продуктовыми командами:

  • Традиционный путь: Аналитик ставит задачу → разработчик пишет код и тесты → код-ревью → прогон пайплайна CI/CD → деплой. Цикл занимает от дней до недель.
  • Путь с Decisions API: Бизнес-правила обновляются изолированно „на лету“ через панель управления или версионируемый конфиг, а приложение продолжает отправлять запросы к стабильному API.

Архитектура интеграция и примеры запросов

Когда продуктовая команда получает ключи от этого API, возникает закономерный вопрос: как подружить внешние правила с нашими текущими сервисами? Разберем это на практическом примере интеграции.

В публичной бете Decisions API опирается на легковесный REST/gRPC-транспорт и декларативные форматы описания правил (например, на базе JSON Schema). Рассмотрим типовой пример запроса для проверки возможности предоставления скидки и бесплатной доставки:

POST /v1/decisions/evaluate
Host: api.decisions.dev
Content-Type: application/json
Authorization: Bearer <TOKEN>

{
  "context": {
    "user_id": "usr_982341",
    "segment": "PREMIUM",
    "cart_total": 4200,
    "region": "MSK"
  },
  "rule_set_id": "checkout_promotions_v2"
}

В ответ сервис возвращает структурированный вердикт, который приложение интерпретирует на уровне бизнес-логики заказа:

{
  "decision_id": "dec_77192384",
  "status": "SUCCESS",
  "result": {
    "free_shipping": true,
    "discount_percent": 10,
    "applied_rules": [
      "rule_premium_threshold_4000",
      "rule_msk_region_bonus"
    ]
  },
  "latency_ms": 12
}

Производительность и отказоустойчивость

Поскольку вынос логики вовне звучит как потенциальный риск для производительности, заглянем под капот сетевых задержек. Поскольку Decisions API находится на критическом пути выполнения запросов (hot path), к нему предъявляются жесткие требования по latency. В текущей бета-версии задекларированы следующие метрики:

  • P99 latency: < 20 мс при локальном кэшировании правил.
  • Availability: 99.9% с автоматическим fallback на локальные резервные правила в случае сетевых сбоев