7-Day Rolling Sum by Store and Product

SQL coding challenge · Difficulty: hard · Topic: Window Functions · +200 XP

Problem

A retail chain tracks daily sales for every product it stocks in every store.

Single days are too noisy to act on, so the operations report carries a

running 7-day total next to each day — enough to see a trend without

waiting for a month to close.

Engine: queries run on MySQL 8.0, so use MySQL-compatible syntax and functions.

Tables

store_product_sales — one row per store, product and day.

| column | type | description |
| --- | --- | --- |
| store_id | INT | the store |
| product_id | INT | the product |
| sale_date | DATE | the day the sales were recorded |
| sales | INT | units sold that day |

Return every row of store_product_sales, with one extra column:

• rolling_7day_sum — the total sales over the current row and the **6 rows

before it, counted within the same store_id and** product_id

Sort the result by store_id, product_id, sale_date — all ascending.

What "7-day" means here

The window is 7 rows, not 7 calendar days: the current row plus the six

rows preceding it in date order. If a product has no row for a date, that date

is simply not there — the window reaches back seven *recorded* days, however

far apart they fall on the calendar.

The window restarts for every (store_id, product_id) pair. The same product

sold in two different stores has two independent running totals, and they never

mix. Where fewer than seven rows exist so far, sum the rows that do exist —

the first row of a pair is always just its own sales.

Example input

store_product_sales

| store_id | product_id | sale_date | sales |
| --- | --- | --- | --- |
| 1 | 1 | 2024-01-01 | 10 |
| 1 | 1 | 2024-01-02 | 20 |
| 1 | 1 | 2024-01-03 | 30 |
| 1 | 1 | 2024-01-04 | 40 |
| 1 | 1 | 2024-01-05 | 50 |
| 1 | 1 | 2024-01-06 | 60 |
| 1 | 1 | 2024-01-07 | 70 |
| 1 | 1 | 2024-01-08 | 80 |
| 1 | 2 | 2024-01-01 | 100 |
| 1 | 2 | 2024-01-02 | 200 |
| 1 | 2 | 2024-01-03 | 300 |
| 2 | 1 | 2024-01-01 | 5 |
| 2 | 1 | 2024-01-02 | 15 |

Expected output

| store_id | product_id | sale_date | sales | rolling_7day_sum |
| --- | --- | --- | --- | --- |
| 1 | 1 | 2024-01-01 | 10 | 10 |
| 1 | 1 | 2024-01-02 | 20 | 30 |
| 1 | 1 | 2024-01-03 | 30 | 60 |
| 1 | 1 | 2024-01-04 | 40 | 100 |
| 1 | 1 | 2024-01-05 | 50 | 150 |
| 1 | 1 | 2024-01-06 | 60 | 210 |
| 1 | 1 | 2024-01-07 | 70 | 280 |
| 1 | 1 | 2024-01-08 | 80 | 350 |
| 1 | 2 | 2024-01-01 | 100 | 100 |
| 1 | 2 | 2024-01-02 | 200 | 300 |
| 1 | 2 | 2024-01-03 | 300 | 600 |
| 2 | 1 | 2024-01-01 | 5 | 5 |
| 2 | 1 | 2024-01-02 | 15 | 20 |

Why store 1 / product 1 ends at 350, not 360. By 2024-01-08 that pair has

eight rows, one more than the window holds, so the oldest day drops out:

20+30+40+50+60+70+80 = 350. A running total that never forgets anything would

report 360 — that is the difference between a rolling sum and a cumulative one.

Why store 2 starts again at 5. Store 2 also sells product 1, but it is a

different pair, so its total begins from scratch rather than continuing store

1's numbers.

What this SQL challenge teaches you

“7-Day Rolling Sum by Store and Product” is a hard-level SQL challenge focused on Window Functions. Working through it gives you hands-on practice with Window Functions — the kind of transformation you are asked to write in real data engineering work and in technical interviews. You can solve it directly in the browser: the dataset is pre-loaded, so you write the query or DataFrame code, run it, and compare your output against the expected result immediately.

How to approach it

If you get stuck, work through these steps in order before looking at a full solution — each one narrows the problem down:

1. You need a total that moves with each row, not one number per group. A window function keeps every row and computes over a frame around it.
2. SUM(col) OVER (...) with a frame clause is the shape. Without a frame you get the whole partition, which is a cumulative total rather than a rolling one.
3. PARTITION BY has to carry BOTH store_id and product_id -- the same product in another store is a separate running total and must not blend in.
4. ORDER BY sale_date inside the OVER clause is what makes "preceding" mean earlier, rather than whatever order the rows happen to be stored in.
5. The frame is seven rows counting the current one. Use ROWS, not RANGE with a day interval: the window reaches back seven recorded rows, and calendar gaps do not shrink it.

Where this comes up

Variations of this problem have been reported in interviews at Amazon. Interviewers use it to check whether you can express the logic cleanly and reason about correctness on edge cases such as ties, nulls and empty groups.

How to practise it on PySpark.in

Open the challenge, write your SQL query in the editor and press Run to execute it against the sample dataset. Submitting checks your output against every test case, including hidden ones, so you find out straight away whether your logic holds up. You can retry as often as you like, and each solved challenge adds to your XP.

Related SQL challenges

• Top 3 Products per Category
• Running Total Revenue
• Median Salary per Department
• Latest Order Per Customer
• 3-Day Rolling Sum of Sales
• 7-Day Rolling Purchase Amount by Customer

Helpful resources

• Learn this concept
• Practice this topic
• Open the notebook

Frequently asked questions

Do I need to install Spark or a database to solve this?

No. The SQL environment runs in your browser with the sample data already loaded, so there is nothing to install or configure.

Is this challenge free?

Yes - the problem, the sample dataset, the hints and unlimited test runs are free.

What level is it?

It is rated hard and covers Window Functions.

Solve this challenge free on PySpark.in