How OLTP and OLAP work together

OLTP and OLAP aren't rivals. In most companies they're two halves of one system: the OLTP side captures what happens, the OLAP side turns it into answers. The pipeline in between is the data engineer's.

This is the common shape, not the only one. Some companies land data in a lake or lakehouse first (section 1.10), process streams, or query sources directly without copying.

Why not just query the app's database?

Imagine the production database handling 10,000 checkouts a minute. An analyst runs a query that scans hundreds of millions of rows with several big joins. Both now compete for the same CPU, memory, disk bandwidth, cache and sometimes locks. Checkout gets slower, and customers notice.

Not every analytical query does damage, and many databases can limit resources per workload. But the usual fixes are:

• A read replica: a copy of the database that follows the primary, for read-only queries.
• Workload management: cap how much CPU and memory reporting queries may take.
• A separate warehouse: copy the data out and analyse it there. The most common answer.

Freshness: how far behind is the dashboard?

An order commits at 10:00:00. The pipeline delivers it to the warehouse at 10:05:00. Until then, the dashboard doesn't show it. That gap is data latency (or ingestion latency).