Syllabus Lesson 42 of 141 · Delete the problem
Delete the problem

Remove a step: the sort nobody needed

Why it matters Pipelines grow by accretion. Each stage made sense to whoever added it. When the pipeline breaks, the reflex is to make the stages stronger, not to ask which ones should be there.

A nightly job turns the order export into revenue per customer for the finance team. It has three stages, shown in the starter code: load the orders, sort them by customer, then total each group. It worked for two years. The export has grown, and the job now dies with an out-of-memory error.

The export arrives as a stream: you get one order at a time and the export is never fully in memory unless your code puts it there. Each order has .order_id, .customer and .cents (negative for a refund).

The obvious fixes add something: a bigger worker, an external sort, a database. Look at what each stage gives the next one first.

Your turn

Fix revenue_by_customer(orders). orders is an iterator of order objects (read it once). Return a list of (customer, total_cents) pairs sorted by customer. Memory rule: at most 1,000 orders may be held in memory at any moment; the test export has 50,000 orders from 800 customers. Totals per customer are fine to keep.

Spotted a problem in this lesson? Report it · Ask about this lesson

This exercise opens soon

Finish the lesson before it and this one unlocks. The whole course is free, no account needed, and you can read this lesson right now.

Start at lesson 1 Back to syllabus