Transactional and Analytical Work

Transactional and analytical workloads may use the same underlying business data, but they ask that data to do two very different jobs. This lesson explains why separating those jobs protects a live application while giving reporting room to run, using the booking system Brightpath runs today as the example.

In this lesson, you will learn to:

• Distinguish OLTP and OLAP workloads by their operation size, frequency, and latency tolerance.
• Explain why running analytical reporting against a live transactional database can degrade application performance.
• Compare ETL and ELT pipelines and state the data-freshness trade-off a nightly pipeline creates.

Think about a booking system. Someone reserves an appointment slot. Someone else changes their phone number. A third person cancels and rebooks. Each of these touches a tiny amount of data, a row or two, and each has to complete right now while the person is staring at the screen. This is online transaction processing, usually shortened to OLTP. The pattern is many small operations, arriving constantly, each one fast, each one reading or writing only a handful of records.

Now think about a different question: "what was our average revenue per site over the last three years, broken down by month?" Nobody is waiting at a screen mid-booking. But answering it means reading millions of rows, adding them up, and grouping them. That is online analytical processing, or OLAP. The pattern is the opposite: a small number of very large operations, each one scanning huge amounts of data, each one tolerant of taking a while.

The distinction matters because these two patterns want different things from a database. Transactional work tends to find a specific record quickly and coordinate concurrent changes. Analytical work tends to sweep across many records without caring about any individual row. A database tuned beautifully for one is a poor fit for the other, and here's the practical consequence you'll run into as a cloud engineer: a report that is perfectly reasonable in isolation can bring a live application to its knees.

The comparison makes the architecture practical: isolate large reporting scans from the live transactions that customers need to complete immediately.