- Project Description
- Features
- System Overview
- Stakeholder Analysis
- Functional Requirements
- Quality Attributes
- Architectural Views
- 7.1 Context Viewpoint
- 7.2 Use Case Viewpoint
- 7.3 Process Viewpoint
- 7.4 Development Viewpoint
- Usability
- Architectural Patterns Used in the Project
- Key Architectural Decisions
- 10.1 Component-based SPA Architecture
- 10.2 Minimalist Modern Design
- 10.3 React Native for Mobile
- 10.4 Microservices with REST/JSON
- 10.5 SQLite Local Storage
- 10.6 Kubernetes Orchestration
- 10.7 Lazy Loading
- 10.8 Multi-DB Deployment
- 10.9 Microservices Isolation
- 10.10 Horizontal Microservices Scaling
- 10.11 Stateless APIs
- 10.12 MVC with ORM
- 10.13 React Native Unified Codebase
- 13.1 Figure 1: System Overview
- 13.2 Figure 2: Context Diagram
- 13.3 Figure 3: Use Case Diagram
- 13.4 Figure 4: Sequence Diagram
- 13.5 Figure 5: Microservices Diagram
- 13.6 Figure 6: Customer UI
- 13.7 Figure 7: Agent UI
- 13.8 Figure 8: Vendor Dashboard
- 13.9 Figure 9: MVC pattern
- 13.10 Figure 10: RESTful API
- 13.11 Figure 11: Key Architectural Decisions
- Syed Mohammad Kashif
- Abdul Raheem Shahzad
- Danish Ali
- Juraev Dilshodbek
This project aims to build a hyperlocal delivery platform tailored for customers located within a 3-mile radius of local shops and food vendors. The platform allows users to browse nearby grocery stores, restaurants, and small-scale food points, view item details including prices and availability, add items to a cart, and place orders for home delivery. Customers receive live updates on their order status—from confirmation to preparation and delivery—and can track the order and delivery agent’s.
To ensure quality and trust, customers are encouraged to leave feedback and ratings for each vendor, product, and delivery experience. This helps other users make informed decisions and motivates vendors and delivery personnel to maintain high service standards.
Vendors have access to a dedicated dashboard where they can manage their inventory, update product availability, set business hours, and view incoming orders. Delivery agents use a mobile interface to accept delivery requests, navigate to destinations, and update the order status at each step.
The platform emphasizes ease of use, responsiveness, and seamless interactions among all user types. Key non-functional goals include maintaining a fast user interface, ensuring high system availability, and reliability. The user experience is designed to be intuitive and efficient, even for individuals with limited digital literacy.
Overall, this system supports the growing demand for convenient, reliable, and locally focused delivery services, fostering stronger connections between neighborhood vendors and their surrounding communities.
-
Customer Mobile Interface:
- Browse local vendors and food points.
- Add items to the cart and place orders.
- Real-time order tracking and delivery status updates.
- Secure payment options and transaction management.
- Ability to leave feedback and ratings for vendors, products, and delivery experiences.
-
Vendor Dashboard:
- Manage inventory and update product availability.
- Set up a business profile and business hours.
- Manage orders.
- View and respond to customer feedback.
-
Delivery Agent Mobile Interface:
- Accept delivery requests and navigate to destinations.
- Update order status at each step of the delivery process.
The platform supports the growing demand for convenient, reliable, and locally focused delivery services. It helps strengthen connections between neighborhood vendors and their surrounding communities by providing an efficient, trustworthy solution for local deliveries.
We included the system's Overview diagram showing the system's end users. It shows that our system has different interfaces for end users, such as the Customer Mobile App for customers and the vendor dashboard for vendors. Then, it shows we have a common API Gateway for the whole system, allowing us to have a single point of entry to the system. It helps us interact with a distributed microservices backend. The system uses RESTful APIs for communication, enabling stateless and efficient data communication between the front and backend. The system also has three central databases to store its data.
Figure 1: Architecture overview diagram showing the overview of system architecture
The following are the primary stakeholders for this hyperlocal delivery platform. Each stakeholder influences the system design based on their specific needs and expectations:
-
Customers: End-users who browse, order, and receive products. Their satisfaction directly impacts platform adoption and success. A seamless and responsive user experience is critical.
-
Vendors: Local shops and food vendors who list products and manage inventory. Vendor participation ensures a wide variety of offerings; they require a stable and reliable system to manage daily operations.
-
Delivery Agents: Personnel responsible for picking up and delivering orders. Their efficiency affects order fulfillment speed and customer satisfaction; they need a simple and dependable app to manage deliveries.
-
Product Owner: Oversees the platform’s strategic direction and growth. They are concerned with building a scalable system that can support future expansions without major redesigns.
-
Developers: Technical team responsible for developing, maintaining, and improving the platform. They prioritize clean, maintainable code to ensure long-term system health and rapid feature updates.
While our hyperlocal delivery platform provides value to customers, vendors, and delivery agents, certain stakeholders may oppose or be negatively impacted by the system. Identifying these groups helps mitigate risks and ensures smoother adoption.
-
Competing Delivery Platforms: These established players may see our hyperlocal model as a threat, especially since we focus on small vendors within a 3-mile radius. They could respond by lowering fees, offering exclusive vendor contracts, or lobbying for regulations that disadvantage smaller platforms. This could limit our vendor partnerships and customer base.
-
Traditional Brick-and-Mortar Retailers (Not on the Platform): Local stores that choose not to join our platform may lose business to competitors who offer delivery. They might discourage customers from using our service, form alliances to exclude us, or resist digital adoption, reducing the variety of vendors available on our system.
-
Neighborhood Residents (Non-Customers): Increased delivery traffic (e.g., bikes, scooters) may cause noise, parking issues, or safety concerns in residential areas. Residents could complain to local officials, leading to delivery restrictions or negative publicity that harms our platform’s reputation.
CUS-1 Browse Items
- The customer shall be able to browse items
- The customer shall be able to search for items
- The customer shall be able to filter items
CUS-2 Add Items to Cart
- The customer shall be able to add items to the cart
- The customer shall be able to remove items from the cart
- The customer shall be able to view cart contents
- The customer shall be able to see the real-time price total
CUS-3 Place Order
- The customer shall be able to initiate checkout
- The customer shall be able to select a delivery address
- The customer shall be able to choose a payment method
- The customer shall be able to confirm the order
CUS-4 Track Order
- The customer shall be able to view the order status
- The customer shall be able to see the delivery agent's location
- The customer shall be able to contact the delivery agent
- The customer shall be able to mark delivery as received
CUS-5 Give Feedback
- The customer shall be able to rate products (1-5 stars)
- The customer shall be able to write text reviews
- The customer shall be able to submit feedback anonymously
- The customer shall be able to edit feedback within 24 hours
VEN-1 Setup Business Profile
- The vendor shall be able to register store information
- The vendor shall be able to upload the business logo
- The vendor shall be able to set service areas
- The vendor shall be able to configure business hours
VEN-2 CRUD (Create, Read, Update, Delete) Products
- The vendor shall be able to add new products
- The vendor shall be able to update product details
- The vendor shall be able to set product prices
VEN-3 add Inventory
- The vendor shall be able to add product inventory
- The vendor shall be able to mark items as out of stock
- The vendor shall be able to mark items as in stock
VEN-4 Accept/Reject Orders
- The vendor shall be able to view new orders
- The vendor shall be able to accept/reject orders
- The vendor shall be able to update the order status
- The vendor shall be able to cancel orders
VEN-5 Send Delivery Request
- The vendor shall be able to see the available delivery agents on the platform
- The vendor shall be able to generate a delivery request when the order is ready
- The vendor shall be able to see who accepted the delivery request
VEN-6 Respond Feedback
- The vendor shall be able to view customer ratings
- The vendor shall be able to reply to reviews
- The vendor shall be able to report inappropriate feedback
- The vendor shall be able to view feedback analytics
VEN-7 Generate Report
- The vendor shall be able to see a report on business performance
- The vendor shall be able to see the stats of orders and profits
- The vendor shall be able to filter the report based on days, weeks, and months
- The vendor shall be able to download the business report
DEL-1 Accept Delivery Requests
- The agent shall be able to view assigned deliveries
- The agent shall be able to accept delivery requests
- The agent shall be able to see delivery locations on the map
- The agent shall be able to view package details
DEL-2 Reject Delivery Requests
- The agent shall be able to view assigned deliveries
- The agent shall be able to reject delivery requests
- The agent shall be able to see deliveries assigned other than rejected ones.
DEL-3 Complete Order Delivery
- The agent shall be able to mark orders as picked up
- The agent shall be able to update the delivery status
- The agent shall be able to collect customer signatures
- The agent shall be able to mark orders as delivered
| Stakeholder | Key Concerns | Relevant Quality Attributes |
|---|---|---|
| Customers | Easy-to-use app for browsing, ordering products, and receiving deliveries quickly. | Usability, Performance |
| Vendors | System must be highly available and consistently operational to manage inventory and orders effectively. | Availability |
| Delivery Agents | Simple, reliable app to accept deliveries and update statuses easily. | Usability, Availability |
| Product Owner | The system architecture should support easy scaling and work across multiple devices. | Scalability |
| Developers | Codebase should be maintainable, allowing for easy updates, improvements, and issue resolution. | Maintainability |
Stakeholder: Customers, Delivery Agents
Concern:
- Customers need an easy-to-use app for browsing, ordering products, and receiving deliveries quickly.
- Delivery agents need a simple, reliable app to accept deliveries and update statuses easily.
Explanation:
- Customers value a seamless, intuitive, and efficient experience when navigating the platform. The mobile interface should allow them to easily browse local vendors, add items to the cart, place orders, and track deliveries in real-time without unnecessary steps.
- Delivery agents also require a user-friendly interface to minimize operational complexity. The mobile interface for them needs to ensure smooth management of delivery requests, real-time status updates, and quick response times to minimize errors and improve delivery speed.
- Usability is crucial for both customers and delivery agents, as it directly impacts their interaction with the platform and their overall satisfaction.
Key Solutions:
- The project employs a minimalist design approach, ensuring the interface is clear and easy to navigate for all user groups.
- Usability is further emphasized by the mid-fidelity design prototypes for the customer, delivery agent, and vendor interfaces.
Stakeholder: Customers
Concern:
- Customers expect a responsive platform that provides fast browsing, ordering, and delivery tracking.
Explanation:
- Performance in this context refers to how quickly the system responds to customer actions, such as browsing for items, adding them to the cart, placing orders, and tracking the delivery status. Delays or slow loading times can negatively impact user satisfaction and engagement.
- Fast performance is vital to keep customers engaged and improve their experience on the platform. The application should deliver real-time updates on delivery status without significant latency.
Key Solutions:
- The system uses lazy loading techniques to optimize performance, ensuring that only necessary resources are loaded initially, speeding up the user experience.
- A component-based SPA (Single Page Application) architecture ensures that customers can transition between pages without full reloads, further improving the perceived performance.
Stakeholder: Vendors, Delivery Agents
Concern:
- Vendors need a system that is highly available and consistently operational to manage their inventory and orders effectively.
- Delivery agents rely on the app being available at all times to accept delivery requests and update delivery statuses.
Explanation:
- Vendors require the system to be continuously available to manage their operations, update their inventory, respond to orders, and track their performance.
- Delivery agents also need uninterrupted access to the system to receive delivery requests and manage orders in real time.
- High availability ensures that no part of the system is down for long periods, minimizing operational interruptions.
Key Solutions:
- The project incorporates microservices architecture to enable high availability, ensuring that individual services can scale and recover independently, reducing the chances of downtime.
- The system uses Kubernetes orchestration for automated scaling, fault tolerance, and self-healing capabilities, ensuring continuous service availability.
Stakeholder: Product Owner
Concern:
- The system architecture should support easy scaling to handle more users, vendors, and delivery agents while working across multiple devices.
Explanation:
- Scalability allows the system to handle increased load as the number of customers, vendors, and agents grows over time. This includes scaling the infrastructure, adding new features, or supporting more users without compromising performance.
- The platform must be designed to support both vertical (increasing resources) and horizontal (adding more instances) scaling to accommodate growing demand.
Key Solutions:
- Microservices architecture facilitates scalability by allowing individual components to scale independently as needed.
- The system also employs Kubernetes for automated scaling and horizontal scaling of microservices, allowing the system to efficiently handle increased traffic and usage.
Stakeholder: Developers
Concern:
- The codebase should be maintainable, allowing for easy updates, improvements, and issue resolution.
Explanation:
- Maintainability refers to the ease with which the system can be updated, debugged, and improved. Developers should be able to identify and resolve issues quickly, as well as implement new features or improvements without causing disruptions to the system.
- A well-maintained codebase reduces technical debt, ensuring long-term stability and enabling faster feature development and bug fixes.
Key Solutions:
- The project follows the Model-View-Controller (MVC) design pattern, promoting modularity and separation of concerns, which improves maintainability by making it easier to update individual components.
- Additionally, the use of ORM (Object-Relational Mapping) for database interaction reduces boilerplate code, enhancing the ease of making future database changes.
The Context View describes the system’s boundaries by showing its interactions with external actors such as users, vendors, delivery agents, and other systems. It highlights what is inside the system and what lies outside, helping stakeholders understand how the system fits into its environment and what major inputs and outputs exist.
The Context Diagram below shows how external entities, such as users and external systems, interact with our system. It shows that vendors provide their products and working hours information to our system, and the system provides customers with orders and business. The customer provides their delivery information and the products they added to the cart, and the system returns order confirmation and tracking of their orders. Similarly, the delivery agent receives the pending orders for delivery and completes the order delivery. Our system also interacts with external systems such as Location API (Google Maps) by providing the addresses and receiving the coordinates (longitude and latitude).
Figure 2: Context view of the system showing the interaction of external entities with our system
The Use Case Viewpoint captures the primary ways different users (customers, vendors, and delivery agents) interact with the delivery platform to achieve their goals. It outlines the major functionalities the system must support, such as browsing vendors, placing orders, tracking deliveries, managing inventory, and updating order statuses. This viewpoint helps in understanding user requirements clearly by focusing on user-system interactions and ensures that the system is designed around real-world activities and expectations of its stakeholders.
Figure 3: Use case diagram demonstrating the use cases for vendor, customer and delivery agent
The Process Viewpoint focuses on the system’s dynamic behavior and describes how different parts of the system interact at runtime to achieve specific tasks. It models processes such as order placement, payment handling, delivery tracking, and inventory updates, often showing how components communicate, synchronize, and handle concurrent activities. In this delivery platform, the process view ensures smooth coordination between customers, vendors, and delivery agents by managing workflows like order processing, delivery assignment, and real-time status updates.
The System Sequence Diagram (SSD) below outlines the step-by-step interactions between the key actors—Customer, Vendor, Delivery Agent—and the Hyperlocal Delivery Platform during an order's lifecycle. The process begins when the Customer browses nearby vendors, selects items, and confirms the order, prompting the System to process payment and notify the Vendor while assigning a Delivery Agent. Next, the Vendor updates inventory, confirms order acceptance, and marks it as ready for pickup, which triggers the System to alert the Delivery Agent and update the Customer on the order status. The Delivery Agent then accepts the request, picks up the order, and provides real-time updates as it moves through "En Route" to "Delivered," with the System relaying tracking information to the Customer. Finally, after delivery, the Customer submits feedback on the Vendor, products, and delivery experience, which the System records for analytics and service improvement. The diagram effectively captures the end-to-end workflow, highlighting real-time coordination, status updates, and seamless communication among all parties involved in the hyperlocal delivery process.
Figure 4: System Sequence Diagram to show interaction between Customer, Vendor, and Delivery Agent
The Development View focuses on the system’s internal structure from a developer’s perspective. It describes how the software is organized in the codebase — such as modules, packages, layers, and components — and how they are built and managed. This view helps developers understand how to develop, maintain, and extend the system efficiently. It also covers aspects like version control, build processes, coding standards, and team organization.
Figure 5: Microservices diagram for hyperlocal delivery system
Product Service
The Product Service manages the product catalog and inventory, ensuring accurate stock levels and product details are available. It serves as the source of truth for product data, which other components like Cart Service rely on to display items and validate availability during checkout.
Cart Service
The Cart Service handles all cart-related operations, such as adding or removing items, calculating totals, and applying discounts. It interacts with the Product Service to fetch real-time product details and passes finalized carts to the Payment Service for checkout.
Order Service
The Order Service is responsible for managing the orders right from their creation to their fulfillment, including changing order status and order cancellation scenarios. It coordinates with the Payment Service for payment confirmation after the Payment Service completes transactions, and also interacts with the Tracking Service to monitor order status post-purchase and provide real-time tracking.
Payment Service
The Payment Service manages all payment processing, including credit card transactions, digital wallets, and refunds. It ensures secure payment authorization and communicates success or failure back to the Order Service, which then updates the order status accordingly.
Tracking Service
The Tracking Service monitors order fulfillment, providing real-time shipping and delivery status updates. It receives order data from the Order Service, tracks and delivers products, and notifies customers of progress.
Feedback Service
The Feedback Service collects and processes customer reviews and ratings linked to orders. This feedback information is required for the Product Service to create the product listing. It also aggregates feedback for analytics, which the Business Profile Service uses to generate vendor performance reports and improve service quality.
Business Profile Service
The Business Profile Service manages vendor profiles, store settings, and business analytics. The vendor profiles also include the product listing, which includes product information, customer reviews, and feedback. It compiles data from orders, payments, and feedback services to provide insights into sales performance, customer satisfaction, and operational efficiency.
We provided mid-fidelity designs to address the usability concerns of end users and to showcase how our system is designed to meet the expectations of users across various devices, including iOS, Android, and the web. This approach allows us to highlight our key architectural decisions aimed at enhancing the user experience. The diagrams illustrate that our design adheres to modern UI/UX principles.
We have adopted a minimalistic design to ensure that our system is easy to use and understand. Additionally, we have created separate user interfaces tailored for different users, including distinct mobile applications for customers and delivery agents, as well as a web dashboard for vendors. This minimalistic approach and the separation of user interfaces contribute to improving the overall understandability of our system, which is an essential aspect of usability.
Figure 6: Mid-fidelity design for customer mobile application
Figure 7: Mid-fidelity design for delivery agent mobile application
Figure 8: Mid-fidelity design for Vendor Dashboard
Our system follows a microservices architecture style compared to a monolithic architecture, and we have a total of seven microservices. The three clients, 1) the Customer mobile app, 2) the Vendor dashboard, and 3) the Delivery agent mobile app, interact with the backend microservices through an API gateway. This interaction is stateless using RESTful APIs, and the communication between these microservices and the clients is through the JSON data format. Figure 5 shows the microservices architecture style of our system.
Quality attributes: Availability, scalability, and maintainability.
We have used Model-View-Controller (MVC) architecture patterns, which separate a system into three distinct components: the Model, which manages data logic; the View, which handles presentation and user interface; and the Controller, which processes input, invokes Model operations, and updates the View. This separation promotes modularity, ease of maintenance, and testability. By isolating business rules from the user interface, developers can work on different components simultaneously without introducing side effects. In server-side frameworks like Laravel, MVC enables clean, organized codebases where models represent database entities, views are templated frontends, and controllers serve as the business logic part.
Figure 10 illustrates the application of the MVC pattern in our system architecture, demonstrated through the interaction between the Product Service and the customer mobile app. The implementation follows these key flows:
When a customer views product information through the mobile app (which serves as the View layer), the app initiates a request to fetch product data via RESTful APIs exposed by the Product Service. This request is first received by the Products Controller, which acts as the intermediary between the View and data operations.
The Product Controller performs several critical functions: it validates the incoming request, processes any required business logic, and coordinates with the Product Model to retrieve the necessary data. The Product Model, representing the data layer, executes the actual data retrieval operations based on the Controller's instructions, typically involving querying the database or other persistence mechanisms.
Upon receiving the requested data from the Product Model, the Product Controller formats and returns the appropriate response to the mobile app View, completing the cycle. This separation of concerns ensures that the View remains focused on presentation, the Controller handles user input and application flow, while the Model manages data access and retrieval.
Quality attributes: Maintainability.
Figure 9: MVC pattern used in Hyperlocal delivery system
We also used the REST API architectural pattern, which is based on stateless communication and resource-based interactions over HTTP. It structures requests around CRUD operations (Create, Read, Update, Delete) on resources, using standard HTTP methods (GET, POST, PUT, DELETE) and returning lightweight JSON payloads. RESTful APIs enable decoupling between frontend clients and backend services, allowing independent evolution of both layers. To enhance scalability, security, and maintainability, an API Gateway can be introduced. The API Gateway acts as a single entry point for all client requests, managing authentication, request routing, rate limiting, and aggregating responses from multiple microservices. This pattern simplifies client-side logic, ensures consistent cross-cutting concerns, and enables backend services to remain focused on business logic. In a microservices architecture, the combination of REST APIs and an API Gateway streamlines communication, enhances system resilience, and supports horizontal scaling.
Quality attributes: Scalability and simplicity.
Figure 10: RESTful API pattern used in Hyperlocal delivery system
- Issue: Traditional multi-page applications cause reloads that interrupt workflows.
- Rationale: Single Page Applications (SPA) provide seamless navigation and faster interactions, crucial for vendor dashboards. Component-based design ensures consistency and reusability across the app.
- Benefits: Smooth user experience with no full-page reloads; consistent design language throughout the app.
- Limitations: Requires more complex client-side state management (e.g., Redux) and might affect initial load time.
- Quality attributes: Usability and performance.
- Alternative Solutions: Use server-side rendering (SSR) frameworks like Next.js to balance performance and interactivity.
- Summary: We chose SPA with React for its seamless UX and performance. SSR was considered but offers less client-side interactivity.
- Issue: Overly complex UI designs increase cognitive load, reducing task efficiency.
- Rationale: Minimalist design simplifies navigation and enhances usability by reducing visual clutter.
- Benefits: Users can complete tasks faster due to intuitive layouts and familiar interaction patterns.
- Limitations: Risk of oversimplifying features or omitting necessary visual cues.
- Quality attributes: Usability.
- Alternative Solutions: Employ user-centered design (UCD) or participatory design to balance simplicity and features.
- Summary: Minimalist design was preferred for its clarity; UCD was considered but adds complexity in rapid delivery.
- Issue: Building separate native apps for iOS and Android increases development and maintenance costs.
- Rationale: React Native provides near-native performance with a shared codebase, reducing costs and improving delivery speed.
- Benefits: Consistent behavior across platforms, reduced development effort, access to native gestures and animations.
- Limitations: May encounter limitations in accessing low-level native APIs; requires bridging in some cases.
- Quality attributes: Scalability, maintianability.
- Alternative Solutions: Use Flutter for high-performance cross-platform development or native development for full control.
- Summary: React Native chosen for its balance of cost, performance, and developer familiarity; Flutter or native could add overhead.
- Issue: Monolithic architectures limit scalability and can become performance bottlenecks.
- Rationale: Microservices allow scaling of individual components, and REST/JSON offers lightweight communication.
- Benefits: Independent scaling, improved fault isolation, reduced data transfer size.
- Limitations: Increased complexity in managing service boundaries and deployments.
- Quality attributes: Performance, scalability.
- Alternative Solutions: Use GraphQL to optimize API communication or gRPC for higher performance.
- Summary: REST/JSON was selected for simplicity and wide compatibility; GraphQL or gRPC were considered but are heavier solutions.
- Issue: Frequent API calls for product data increase load times and data usage.
- Rationale: Local storage caches frequently accessed data, reducing API calls and enabling offline access.
- Benefits: Improved load times, reduced mobile data usage, offline functionality.
- Limitations: Risk of stale data if synchronization is not managed properly.
- Quality attributes: Performance.
- Alternative Solutions: Use AsynStorage or Realm DB (for mobile) for more advanced local data management.
- Summary: SQLite was chosen for simplicity; Realm offer more features but add complexity.
- Issue: High-availability requirements for backend services under dynamic loads.
- Rationale: Kubernetes provides automated deployment, scaling, and self-healing capabilities.
- Benefits: High availability, automatic scaling, fault tolerance, and load balancing.
- Limitations: Steep learning curve, additional overhead for managing Kubernetes clusters.
- Quality attributes: Performance, availability.
- Alternative Solutions: Use serverless architectures (e.g., AWS Lambda) or Docker Swarm.
- Summary: Kubernetes was chosen for robust orchestration; simpler alternatives were considered but lacked required capabilities.
- Issue: Loading all resources upfront increases initial page load time.
- Rationale: Lazy loading defers non-critical resources, improving perceived performance.
- Benefits: Faster initial page loads, reduced server bandwidth.
- Limitations: Possible delays in loading deferred resources when needed.
- Quality attributes: Performance.
- Alternative Solutions: Implement critical resources and prioritized loading, or use CDN edge caching.
- Summary: Lazy loading provides direct benefits with minimal complexity; CDN strategies are good but secondary.
- Issue: A Single database failure can cause downtime.
- Rationale: Active-active replication distributes load and ensures failover capabilities.
- Benefits: High availability, resilience to regional failures, and distributed reads.
- Limitations: Increased complexity in replication and consistency management.
- Quality attributes: Availability.
- Alternative Solutions: Use managed distributed databases like Amazon Aurora Global or Google Cloud Spanner.
- Summary: Multi-DB replication was chosen for control and resilience; managed solutions were considered, but they add vendor lock-in.
- Issue: Failures in one part of the system can cascade and affect the entire system.
- Rationale: Isolating services ensures faults remain contained.
- Benefits: One service failure (e.g., payments) does not affect others (e.g., product catalog).
- Limitations: Requires robust inter-service communication and monitoring.
- Quality attributes: Availability.
- Alternative Solutions: Use modular monolith.
- Summary: Service isolation chosen for clear fault boundaries; modular monolith is simpler but less scalable.
- Issue: Sudden increases in load can overwhelm services.
- Rationale: Horizontal scaling adds instances of services under load.
- Benefits: Scalability with predictable performance.
- Limitations: Requires effective load balancing and monitoring.
- Quality attributes: Scalability.
- Alternative Solutions: Use serverless functions for automatic scaling without managing infrastructure.
- Summary: Horizontal scaling offers predictable control; serverless functions were considered but have cold start penalties.
- Issue: Stateful APIs complicate scaling due to session management.
- Rationale: Stateless APIs simplify scaling and load balancing by removing session dependency.
- Benefits: Easy horizontal scaling, reduced complexity.
- Limitations: Requires external session management (e.g., Redis) if needed.
- Quality attributes: Scalability.
- Alternative Solutions: Use web sockets.
- Summary: Stateless APIs are chosen for their simplicity; web sockets add complexity and are suitable for real-time applications.
- Issue: Coupled business logic and presentation layers increase complexity and maintenance costs.
- Rationale: MVC separates concerns, and ORM reduces boilerplate while managing database interactions.
- Benefits: Clean code structure, reduced development overhead, version-controlled schema changes.
- Limitations: ORM can introduce performance overhead for complex queries.
- Quality attributes: Maintainability.
- Alternative Solutions: Use MVVM (Model-View-ViewModel) or micro-ORMs like Dapper or raw SQL for performance-critical parts.
- Summary: MVC with ORM was chosen for its maintainability; MVVM, micro-ORMs/raw SQL are alternatives but increase manual work.
- Issue: Maintaining separate iOS and Android codebases leads to duplication of work.
- Rationale: React Native allows sharing most of the code, reducing maintenance and delivery effort.
- Benefits: Single codebase, faster bug fixes, unified CI/CD pipeline.
- Limitations: Limited access to certain native modules, may need custom bridging.
- Quality attributes: Maintainability.
- Alternative Solutions: Use Flutter for even more unified code or native development for full control.
- Summary: React Native chosen for simplicity and shared code; Flutter and native were considered but add complexity.
Figure 11: Relationship between key architectural decisions.
- We chose to use the microservices architectural style, and because of this decision, we also had to decide how to handle data communication and access to the microservices.
- Without microservices, a monolithic architecture might have used direct method calls or a shared database, making RESTful APIs and an API Gateway unnecessary.
- Therefore, we decided to use RESTful APIs for communication over HTTP(s) and adopted an API Gateway as the single entry point to backend microservices.
- Since we are using microservices, which are deployed as independent containers, we need to decide how to manage these containers at scale.
- Without microservices, container orchestration tools like Kubernetes would be irrelevant (e.g., a monolithic app could run on a single server).
- Thus, we decided to use Kubernetes for orchestration and horizontal scaling to manage microservices efficiently.
- The decision to have separate user interfaces for different users required us to select appropriate technologies for each frontend.
- If we had a single UI, React.js for a web dashboard and React Native for mobile apps would not be needed—a single framework would be enough.
- As a result, we chose: Component-based SPA (React.js) for the web dashboard, React Native for cross-platform mobile apps (customer/delivery agent).
- Because we chose React Native for mobile apps, we needed local data storage, leading to the decision to use SQLite.
- Without React Native (e.g., if we used a pure web app), SQLite would be irrelevant—alternatives like IndexedDB (web) might apply.
1 - Reflections on the REST architectural style and principled design of the modern web architecture
3 - Flexible Self-Management Using the Model-View-Controller Pattern
4 - Web-application development using the Model/View/Controller design pattern
5 - Comparative Analysis of Microservices and Monolithic Architectures in Cloud Deployment
6 - Microservices Architecture for Cloud Computing
7 - Tutorial: Prepare a Single Page App with React for Azure AD Authentication
8 - Modern Single Page Application Architecture: A Case Study
9 - Microservices Architecture Using Docker and Kubernetes
10 - RESTful Microservices with Open Liberty
11 - Prospects for Using React Native for Developing Cross-platform Mobile Applications
12 - Scalable Fault Tolerance for Microservices-Based Systems
| Date | Task Description | Contributor |
|---|---|---|
| 2025, April 6 | Discussion and selection of project ideas for MSA course project. | Syed, Danish, Shahzad, Juraev |
| 2025, April 6 | Finalized the idea of a hyperlocal delivery platform and created the GitHub repository. | Syed, Danish, Shahzad, Juraev |
| 2025, April 6 | Drafted 150-word and 250-word project descriptions for GitHub and course use. | Syed, Danish, Shahzad, Juraev |
| 2025, April 15 | Created system overview diagram and written explanation of the system architecture. | Syed, Shahzad |
| 2025, April 15 | Stakeholder analysis and identifying stakeholders' key concerns (quality attributes) | Syed, Danish, Shahzad |
| 2025, April 15 | Writing of functional requirements and quality attributes. | Syed, Danish, Juraev |
| 2025, May 05 | Created Use case diagram and context diagram to provide the use case view of the architecture. | Syed, Danish, Shahzad, Juraev |
| 2025, May 05 | Created the system sequence diagram to show the process view of the system. | Syed, Shahzad |
| 2025, May 07 | Created the mid-fidelity design of the system to show the usability view of the system. | Syed, Danish |
| 2025, May 07 | Listed the key architecture decisions, how it addresses the quality attributes and potential trade-offs. | Syed, Danish, Shahzad, Juraev |
| 2025, May 15 | Created the mid-fidelity design of the system to show the usability view of the system. | Syed, Danish |
| 2025, May 21 | Created the diagrams for architectural patterns used in the project. | Syed, Shahzad, Danish |
| 2025, May 23 | provided architectural decisions in proper format and provided alternative solutions. | Syed, Shahzad,Juraev |
| 2025, May 25 | Identified relationships among decisions and drawn decision space diagram. | Syed, Danish, Shahzad |
| 2025, May June 1 | Redesigned the Context diagram and improve it's explanation | Syed, Danish, Juraev |
| 2025, May June 5 | Redesigned the MVC pattern diagram and added explanation in the context of our project. | Syed, Shahzad, Danish |
| 2025, May June 15 | Improved the microservices diagram and added it to the development view | Syed, Shahzad, Juraev |
| 2025, May June 16 | Provided examples of relationships among decisions and improved decision space diagram. | Syed, Danish, Shahzad |