> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reelevant.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture & Lifecycle

> System architecture, data flow, and request lifecycle of the Reelevant personalisation engine — from image request to individualised response.

## Request Lifecycle

Reelevant is the only **content-first personalisation engine**. Build Content once — the platform creates millions of individualised versions at the moment of interaction, not at send time.

The following sequence diagram shows the end-to-end flow from a user opening an email (or visiting a page) to receiving personalised Content.

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
sequenceDiagram
    participant User as User (Email/Web/Mobile)
    participant Edge as Reelevant Edge (CDN)
    participant Runner as Runner (Execution Engine)
    participant Cache as Data Cache
    participant DS as Datasources
    participant Events as Event Stream

    User->>Edge: HTTPS GET /workflowId?uid=customerId
    Edge->>Runner: Route to nearest region

    Runner->>Runner: 1. Extract customer ID from URL params
    Runner->>Cache: 2. Fetch customer Datasource records
    alt Cache hit
        Cache-->>Runner: Cached records
    else Cache miss
        Cache->>DS: Live query
        DS-->>Cache: Fresh records
        Cache-->>Runner: Records (now cached)
    end

    Runner->>Runner: 3. Execute Workflow DAG
    Note over Runner: Evaluate Conditions, Splits,<br/>fetch additional Data Nodes

    Runner->>Runner: 4. Select Output Node
    Runner->>Runner: 5. Render Content with bound data

    Runner-->>Edge: Personalised image/HTML/JSON
    Edge-->>User: Response (with cache headers)

    Runner--)Events: Capture impression event
    Note over Events: Click tracking via<br/>redirect URL
```

## Lifecycle Steps in Detail

1. **Request:** Your ESP/website/app includes a Reelevant URL (`https://reelevant.run/{workflowId}?uid={customerId}`). The user's client requests it.
2. **Edge routing:** The CDN terminates TLS and routes to the nearest execution region.
3. **Customer identification:** The URL contains a customer identifier (query parameter) mapped to Datasource records. This identifier is public by design — use opaque IDs.
4. **Data retrieval:** The Runner fetches the customer's current data from connected Datasources (from in-memory cache with live fallback).
5. **Workflow execution:** The DAG evaluates Conditions, retrieves additional data via Data Nodes, and traverses Branches to select the appropriate Output Node.
6. **Content rendering:** The selected Content is rendered with individual data (product images, prices, offers, text) and returned as image, HTML, or JSON.
7. **Event capture:** An impression event is recorded. Click interactions are captured via redirect URLs for future Workflow logic and analytics.

## Infrastructure Guarantees

| Metric                     | Guarantee                                           |
| -------------------------- | --------------------------------------------------- |
| Availability               | 99.9% SLA (measured monthly)                        |
| Data encryption at rest    | AES-256                                             |
| Data encryption in transit | TLS 1.3                                             |
| Data residency             | EU (additional regions planned)                     |
| Throughput                 | 100M+ personalised Content renders/month per client |
| Failover                   | Multi-region active-active                          |

## Next Steps

<CardGroup cols={2}>
  <Card title="Data Ingestion" icon="database" href="/why-reelevant/technical-evaluators/data-ingestion">
    DataHub source types and ingestion modes.
  </Card>

  <Card title="Integration Channels" icon="plug" href="/why-reelevant/technical-evaluators/integrations">
    Email, web, mobile, and JSON API patterns.
  </Card>
</CardGroup>