1. OKRs -> why?
2. Problems
   1. Impossibility of modifying the table
      1. Example: add index to stores
   2. Hard to add new features (remakes, pickup, self cancellations)
      1. New features -> more join queries
      2. Examples
         1. Remakes
         2. Pickup
         3. Self cancellations
   3. No aggregations (plain object with everything)
   4. Postmortems
      1. Orphan orders can't be reviewed
      2. Migration of alternative_payment_methods
   5. Table with too many indexes (to be confirmed)
      1. The fewer indexes you have, the better, while indexes improve the efficiency of queries, they also reduce the efficiency of inserts and updates.
      2. When we create a joint index, such as (k1, k2, k3), it is equivalent to creating (k1), (k1, k2), and (k1, k2, k3) three indexes, which is the leftmost matching principle.
3. Opportunities
   1. Decoupling: events and data replication
   2. Having an aggregated table focused on access patterns
   3. Removing old data (which could enable us to update the table)
   4. Describe the access patterns
   5. Provide aggregated metrics of orders (i.e.e avg $ per restaurant, last order at a restaurant for a given customer)
4. Order use cases
   1. Delivery process
   2. Pricing
   3. Finance
   4. Partners
      1. Invoicing
      2. Top products
   5. Customers
      1. Past orders
      2. Unrated orders
      3. Cancellations
   6. Operations support
      1. Orphaned orders
      2. Admin dashboard
         1. Mostly live orders, short liveness with high amount of indexes
   7. Couriers
      1. Earnings
      2. Past orders
   8. Business reports
5. Support for verticals
   1. Groceries
   2. B2B
   3. Quiero/courier
   4. Store orders
   5. Marketplace