Data Architecture Case Study — Pizza Dash Ordering System

7 min readOct 14, 2023

This is the kick-off to a series of data architecture case studies designed to prep both current and aspiring data architects for their technical interviews.

These aren’t just hypothetical; they’re real-world cases I’ve encountered in my career. Sometimes, I was the one asking the questions, and other times, I was on the receiving end. Though I’ve made a few tweaks for clarity and confidentiality, the core challenges remain the same. A quick heads up: Most companies I’ve worked with (or for) believe there’s no single ‘right’ or ‘wrong’ answer. It’s not just about the solution, but the journey you took to get there and the reasoning behind your choices. So, while I’m sharing one possible approach, there are countless other viable ones out there. Got a different solution or spot something iffy with mine? Chime in! Constructive discussions and shared insights are how we all grow.

This case study is quite comprehensive, so I’ll be focusing on the overarching flow, the data model and high level technology choices for storage. Aspects such as data quality, data security, data privacy, customer identification methods, and enhancing customer experience through data won’t be delved into in this article. I hope in the future I can create a Part 2 article with this information.

Pizza Dash Ordering System — Case Statement

Objective: Develop an ordering system for Pizza Dash, a popular fast-food chain spread across the UK with approximately 250 restaurants.

1. System Requirements

Pizza Dash envisions an application that:

Facilitates customers in placing and tracking their orders.
Manages the order journey from kitchen preparation to delivery via various delivery partners.
Serves customers from any location in the UK.
Features:
— Secure payment processing.
— Real-time order tracking.
— Customer recognition with insights into past orders and recommendations.
— Storing order data for business analytics and future reference.

2. Data Flow & Features

Ordering Process

1 — A customer places an order via the mobile app or website.

2 — The order undergoes:

Payment processing through a gateway.
Asynchronous acknowledgement from the designated restaurant.
Continuous order tracking.
Transfer to a partnered delivery agency for final delivery.

System Capabilities

Withstand high traffic during rush hours without order loss.
Recognise repeat customers and provide pertinent suggestions.
Offer real-time updates at each stage of the order.
Ensure data quality and integrity.

Key Pillars

Data consistency and security.
Scalability.
High availability.
Load management.

3. Task Overview

The assignment is to conceptualise an architectural solution meeting these requirements. Kindly furnish a high-level architectural diagram and elucidate the data flows and journey within the proposed architecture.

Proposed Solution

The Pizza Dash Ordering System encompasses a mobile app and the central-backend supporting it. The diagram below shows the high level data flows that will be explained in detail. We will be only covering the Happy Path flow (nothing fails, every resource is available, no exceptions are found).

We distinguish between two kinds of data flows: synchronous and asynchronous. The synchronous flow involves real-time data integration, usually characterised by point-to-point integration. On the other hand, the asynchronous flow is often associated with a publish/subscribe (pub/sub) messaging integration.

High Level Diagram

The journey is as follows:

1 —When a customer places an order via the mobile app, it involves three data entities in a synchronous data flow: Customer, Order, and Order Detail (refer to the data model section below). This real-time integration with the backend system typically communicates using a JSON message payload with the following structure:

{
  "customer_order": {
    "customer": [
      {
        "customer_num": "1",
        "first_name": "Peter",
        "last_name": "Parker",
        "email": "p.parker@gmailo.com",
        "phone_num": "4422522289988",
        "address": "11 Parker Street KK001",
        "order": [
       {
       "order_num": "100050223",
       "order_datetime": "15-05-2023 14:02:01",
       "order_status": "Submitted",
       "payment_method_details": "payment_method_data",
       "order_detail": [
        {
        "order_det_num": "1",
        "product_num": "10002",
        "price product_qty": "2,99",
        "product_qty": 3
         } ,
         {
        "order_det_num": "2",
        "product_num": "10005",
        "price product_qty": "7,99",
        "product_qty": 2
         } 
         ]
    } ]
      }
    ]
  }
}

2 — Upon reaching the backend, the system invokes the payment gateway to authorise the payment card. (Please note: For simplicity’s sake, we’ve streamlined payment method details like the payment card within the order data entity. In a more detailed scenario, a distinct ‘payment method’ data entity would be required.)

3 — After authorisation, the payment is secured but not yet deducted. It’s essential not to finalise the charge until the restaurant acknowledge and accept the order.

4 — Upon securing the payment, the order’s status updates to “Payment Authorised”. The restaurant, however, has not yet confirmed the order at this point.

5 —Restaurants are set up to receive notifications for new “Payment Authorised” orders intended for delivery within their pre-defined zones. As these orders arrive, the restaurant must acknowledge and approve them. Once that’s done, the order status transitions to “Order Accepted”.

6 — The restaurant then broadcasts various order status updates, which can be accessed in real-time by both the customer and the delivery partner.

As the restaurant processes the order, its status gets updated according to the progress made. Once it’s nearing completion, the status transitions to “Ready to Deliver”. This status might be initiated a few minutes before the order is genuinely ready, ensuring the delivery partner courier can time their arrival efficiently. For facilitating deliveries, there are a couple of options: either directly integrate order data with the delivery partner or establish a new ‘delivery’ data entity to forward delivery requests. I lean towards the latter approach, as it allows for potential bundling of multiple orders and the flexibility to append more information if required.

A delivery payload would look like this :

{
  "delivery": {
    "delivery": [
      {
        "delivery_num": "100554",
        "customer_first_name": "Peter",
      "phone_num": "4422522289988",
      "address": "11 Parker Street KK001",
      "courier_code": "FJ00025",
      "order": [
       {
       "order_num": "100050223",
       "order_datetime": "15-05-2023 14:02:01",
       "order_status": "Ready to deliver",
       "restaurant_num": "Pizza Dash London1"
          } 
         ]
    } ]
      }
    ]
  }
}

7 — Upon an order reaching the “Ready to Deliver” status, the backend system generates delivery requests to inform the delivery partner.

8 — The delivery partner’s system then assigns these orders to a suitable courier, based on predetermined delivery zones. Once a courier confirms the pickup, the delivery partner’s system updates with an acknowledgement of the accepted delivery.

9 — During the delivery process, the courier continually updates the delivery’s real-time location and status in the delivery partner’s system. Pizza Dash routinely checks this status. Eventually, when the courier completes the delivery, both the order and delivery statuses are updated to “Delivered”. Both the restaurant and the customer’s app are designed to track the order’s location and delivery status in real-time.

10- After both the delivery and the order are marked as “Delivered”, the previously secured payment is processed and charged to the customer’s card. This action concludes the process for the customer, restaurant, and delivery partner.

Data Model

While one could opt for a conceptual data model, I prefer starting with a preliminary draft of the logical model. I then refine this draft as I delve deeper into the case study. This model highlights the primary data entities, their key fields, and the relationships.

Storage Options

The selected database technology should satisfy the following criteria to ensure optimal performance and security:

Data consistency and security
Scalability
High availability
Load management

For the mobile application, I would choose a NoSQL database, such as Couchbase or something similar. These options are ideal for handling JSON format data and are known for their scalability and availability.

When it comes to the central system, a NoSQL database offering low latency for both read and write operations could be effective. Choosing a distributed database like Apache Cassandra, known for its replication capabilities and high failure tolerance, might be a fit.

A relational database could also be a consideration for the central system, especially if there’s an anticipation of extensive reporting and analytics needs. However, this would largely hinge on the specific requirements for data analysis.

Assumptions for the Pizza Dash Ordering System

Product management, including pricing, is centralised and not determined by individual restaurants. For the sake of simplicity, we’re not storing any payment method details, even if they could be stored without masking.
Forecasting for demand and supply is assumed to be accurate, ensuring every order can be executed as per the model.
When an order is placed via the mobile app, the data is saved both on the mobile device and the central system (DB) simultaneously.
There’s a consistent synchronisation happening between the mobile database and the central database at regular intervals (every N seconds).
Our focus in this solution is on data and pipelines rather than specific software architecture or vendor solutions.
The sequence of operations is such that orders are first recorded in the Pizza Dash Order System, after which payment is processed.
Since restaurants don’t operate around the clock, they specify their working hours for order acceptance.
The data flow always run on the happy path. No exceptions are shown in the solution.