Javi on DataData • AI • Cloud Engineering

Popular topics

↑↓ to navigate↵ to openEsc to close

Production engineering

Modern Report Engine

How applications, UIs and APIs interact with analytical data.

A Report Engine sits between applications and the data platform. It validates requests, applies security and tenant rules, decides whether to use cached or live data, executes queries when needed, and returns results in formats such as JSON, CSV or downloadable files.

This section explores how to design that system for performance, security, scale and observability.

  1. ClientsWeb UI · Mobile · External API
  2. API GatewayAzure API Management
  3. Report EngineApp Service or Azure FunctionsAuth · validation · tenant rules
  4. CacheAzure StorageHit: reuse the stored output
    FabricWarehouse · SQL endpointMiss: run the query
  5. ResultJSON · CSV · File

What is a Report Engine?

A Report Engine is a backend service responsible for turning a validated report request into data. It can serve web UIs, mobile applications, external APIs, scheduled exports and downloadable reports.

It centralizes request validation, authorization, tenant isolation, controlled query execution, caching, formatting, monitoring and auditing. The frontend sends intent; it should not build database queries directly.

Architecture

A production design on Azure and Microsoft Fabric: who calls the engine, what it checks, where data and cached outputs live, how results leave, and what is monitored.

1 Consumers

Web UIDashboards, filters, downloads
External API clientsPartners and integrations
HTTPS · Entra ID token

2 Edge

API ManagementAzure API ManagementToken validation · rate limits · routing · correlation ID
Admitted request

3 Report Engine

Report EngineApp Service or Azure Functions
  1. 1Authenticate & authorizeCaller, report and format allowed
  2. 2Validate requestRanges, filters, row and byte limits
  3. 3Tenant rulesTenant from trusted claims only
  4. 4Cache lookupKey: tenant · report · params · format · version
  5. 5Query builderApproved templates, bound parameters
  6. 6Result builderJSON · CSV · Parquet
Cache miss: parameterized T-SQL

4 Microsoft Fabric

Fabric WarehouseMicrosoft FabricCurated serving tables
Lakehouse SQL endpointMicrosoft FabricRead-only T-SQL over Delta tables
Cache lookup · write outputs

Cached and generated outputs

Report cacheAzure Storage AccountRead on cache lookup, written by the result builder
  • Azure Storage Account · private endpoint, encryption at rest
    • report-cacheBlob container for report outputs
      • {tenant}Tenant boundary: access and cache keys start here
        • {report-name}One folder per report definition
          • {yyyy}/{mm}/{dd}Date partitions; lifecycle rules expire old outputs
            • {request-id}.{format}One output per request: json · csv · parquet

Example report-cache/contoso/sales-by-region/2026/10/03/7f3c9a1e.csv

Output path

  1. Small, bounded result

    1. Result builder
    2. JSON in the response
    3. Web UI or API client

  2. Large result or file

    1. Result builder
    2. CSV / Parquet written to Storage
    3. Short-lived download link
    4. Client downloads

  3. Long-running request (asynchronous)

    1. POST /reports
    2. 202 Accepted + request ID
    3. GET /reports/{id} status
    4. Download link when succeeded

    Status: queued · running · succeeded · failed · expired

Monitoring Azure Monitor · Application Insights

  • Request and correlation IDs
  • Latency per step
  • Cache hit rate per tenant
  • Fabric query duration
  • Failures, throttling and retries
Report Engine on Azure and Microsoft Fabric. Requests pass API Management and the engine’s checks; cache hits are served from the tenant’s folder in the Storage account, misses query Fabric. Small results return as JSON, larger files are written to Storage and delivered through a short-lived link. Every step reports to monitoring.

Request lifecycle

What happens to one request, step by step, and which component does the work.

  1. API Management

    Receive request

    Assign a request ID, accept a correlation ID

  2. Report Engine

    Validate request

    Report, format, date range, row and byte limits

  3. Report Engine

    Resolve tenant & security

    Tenant from trusted claims; authorize report and filters

  4. Storage account

    Check cache

    Tenant-aware key; fresh output → skip to step 6 or 8

  5. Microsoft Fabric

    Query Fabric if needed

    Approved template, bound parameters, timeout

    Only on a cache miss

  6. Report Engine

    Build result

    Shape rows into JSON, CSV or Parquet

  7. Storage account

    Store output / cache result

    Write to the tenant’s folder with a TTL

  8. Report Engine

    Return response

    JSON body or short-lived download link

The lifecycle of one report request. Steps 1–4 always run; step 5 runs only on a cache miss; every request ends with a stored or reused output and a response that carries its request ID.

Cache: hit or miss

How the engine decides between a stored output and a live Fabric query, without ever sharing results between tenants.

  1. RequestValidated, tenant resolved
  2. Cache keytenantreportparametersformatversion
  3. Look upIn report-cache, under{tenant}/{report}/…
  4. Cached and fresh?Within the report’s TTL

Yes Cache hit

  1. Authorize again for this caller
  2. Read the stored output
  3. Return result

No Cache miss

  1. Query Fabric (approved template)
  2. Build output: JSON, CSV or Parquet
  3. Store under the tenant’s path, with a TTL
  4. Return result

Tenant-aware: same report, same parameters, different tenants

  • contosocontoso · sales-by-region · 2026-09 · csv · v3report-cache/contoso/sales-by-region/…
  • fabrikamfabrikam · sales-by-region · 2026-09 · csv · v3report-cache/fabrikam/sales-by-region/…

Two keys, two folders: never shared.

Cache hit or miss. The tenant is the first part of the cache key and of the storage path, so two tenants asking for the same report with the same parameters never share an entry. A hit is still authorized; a miss queries Fabric and stores the new output for the next request.

Learn

Reference

DiagramCloud & Automation

Report Engine Architecture Reference

A concise reference for report request validation, cache decisions, Fabric queries, asynchronous delivery and observability.

Trace UI and API requests through a secure report engine, tenant-aware cache or query path, result construction, asynchronous delivery, and monitoring.

  • Data Architecture
  • API
  • Reporting
  • Caching
  • +3

View architecture reference →

Build

The planned project will become the executable reference implementation for this architecture.

View project →

Monitoring the Report Engine

Planned Topics

Performance & Caching

API & Delivery

Security

Architecture

Governance & Evolution

View the complete editorial roadmap →