The Aggregation Confusion
A few days back, during one of our whiteboarding sessions with the engineering team, we came across an interesting problem which is seemingly basic to solve. This article will describe a few approaches attempted to solve the problem.
The Product:
The product is a mobile application that can be used by a customer to make e-commerce purchases from the comfort of their home. The customer can place an order, make the payment and manage orders from the app.
Objective:
To build an order history section in the app which can help customers manage their orders. Additionally, from an implementation perspective the solution should have a standard structure and should be scalable.
The Problem:
Through the order history section, the user will be able to view all their recent orders(latest first). On selecting an order, the user will be redirected to the Order Details section where they can view Order Item Status and cancellation or refund information, if any.
Order Status: The following scenarios could take place when a customer places an order on the platform:

Problem from an Implementation Perspective:
a) Supposing the order history section is paginated, will the pagination be on the Order Items (3 + 1 + 2 as defined in the wireframes above) or will the pagination be 3 orders?
b) If the pagination is on the entire order, what if one order has 15 items, one has 2 items and the other has 1? How can all these items be displayed on the screen?
How can the orders be aggregated while keeping the query less complex and standard across?

Whiteboarding
Suggestion 1 : Cap the items displayed under each order to a maximum of 3 and display 10 orders on the page. Counter: What if an order has less than 3 items? The query will be different for all items
Suggestion 2: Display each item as an individual entry and paginate on order item instead of order. Counter: Fetching the item price and item status could increase page load time when the number of orders increase
Suggestion 3: Look for inspiration! While checking the order history section of a few e-commerce apps, we realised that most of the order history sections consist of orders that are grouped by vendor/merchant/brand and no pricing or status information is displayed on the order history page.
The Current Approach
While all the three suggestions are seemingly plausible(or not!), the one that resonated with the product team the most was Suggestion 1 wherein, the order history will be grouped by Order and capped at displaying 3 order items per order. Suppose the order has < 3 items, only the 1 or 2 items will be displayed and the user can select the order to view order details.