Deal Engine Architecture

This section describes the approach UTA will take to build a flexible and evolvable architecture for the deal engine that meets the goals described in the deal engine introduction.

In our approach, a deal is an instance of a deal type. Every deal instance can be one and only one type.

Deal types are defined through deal models.. Deal models are not solely data models, such as might be described in an entity-relationship diagram or a JSON schemna, but descriptions of the computations available.

Deal types are implemented as programs, because deals cannot be adequately described in data models alone. Since deals have their own business rules, initialization logic, and calculations, they must be described both as data models and as computation. It is therefore best to think of each deal type as a small program ("deal program") that can be executed by the deal engine.

Deal data is exposed from the deal program via standardized interfaces, reached as API endpoints. Departmental systems look at the deal program's interfaces rather than referencing a single canonical schema. Each deal program owns its own schema and data model which remains largely hidden from departmental systems.

Deal programs ("deal types") are versioned and registered in a deal registry. Departmental systems find the deal types in the registry.

C4Container
title Deal Engine Platform - C4 Container View (Deal Programs as Microservices)

Person(caller, "Calling Program", "Discovers deal types, then calls standardized deal APIs")

System_Boundary(platform, "Deal Engine Platform") {
  Container(registry, "Deal Registry", "Service (+ DB)", "Catalog of deal types, versions, and service endpoints for discovery")
  Container(gateway, "Deal API Gateway / Router (optional)", "Service", "Stable entrypoint that routes requests to the right deal program service using the registry")

  Container_Boundary(dealServices, "Deal Program Services (one per Deal Type)") {
    Container(dealSvc, "Deal Program Service (Deal Type) vN", "Microservice", "Implements rules, initialization, calculations; exposes standardized interfaces; owns schema")
    ContainerDb(dealDb, "Deal Store (owned schema)", "DB", "Deal instances + private schema owned by this deal type")
  }
}

Rel(caller, registry, "Discover deal type + version → get endpoint metadata", "HTTPS")
Rel(caller, dealSvc, "Call standardized deal endpoints (direct)", "HTTPS")
Rel(caller, gateway, "Call standardized deal endpoints (via gateway)", "HTTPS")

Rel(gateway, registry, "Resolve deal type + version", "HTTPS")
Rel(gateway, dealSvc, "Route/forward to selected deal program service", "HTTP/gRPC")

Rel(dealSvc, dealDb, "Read/write deal instances (private schema)", "SQL/NoSQL")
Rel(dealSvc, registry, "Register/publish deal type versions + endpoints", "CI/CD publish")

Domain Boundaries

There are also important principles describing what the Deal Engine must not do:

1. While the deal engine may consume data from the Authoritative Data system, the deal engine should not “know”, or depend on the data from any other system.

2. The deal engine shall provide only the services described by the interfaces described in this documentation, and no other services.

3. The deal engine must not take on responsibility for business processes that should be provided by downstream systems, such as revenue recognition or commission structure management.