<> Project: Design_Document
Version NO. - 1.00
Authorised by -
1
Confidentiality Agreement
<Insert confidentiality clause and copy Right>
Revision History
Version Date Author Reviewer Approver Comments
1. Introduction
1.1 Scope of the Document
This document provides a high-level architectural design of the Ice Cream Truck
App, defining its structure, components, and interactions. It serves as a blueprint
for development, outlining key technical decisions, system behavior, and design
principles.
1.2 Intended Audience
Development Team
Solution Architects
2
Product Owners
Quality Assurance Team
DevOps Engineers
Business Stakeholders
1.3 System Overview
The Ice Cream Truck App is a mobile-based solution that allows customers to
locate and order from nearby ice cream vendors in real-time. Vendors can update
their availability, manage their menu, and accept or reject orders. The system is
designed for scalability, security, and real-time responsiveness.
Sample content:
2. System Design
2.1 Architecture Overview
The system follows a monolithic backend architecture using Node.js with Express,
deployed on AWS EC2. The database is hosted on PostgreSQL (AWS RDS). Real-
time updates are handled via WebSockets, and load balancing is managed
through AWS ELB (Elastic Load Balancer) with Route 53.
2.2 Key Components
Frontend: React Native (Expo) mobile application.
Backend: Node.js Express server hosted on AWS EC2.
Database: PostgreSQL on AWS RDS.
Caching: Service-level caching enabled for high-volume vendor data.
Real-time Updates: Implemented using WebSockets.
Load Balancer: AWS ELB connected to Route 53.
3
Rate Limiting: Configured via Nginx.
(Architecture Diagram to be included)
3. Application Design
3.1 Process Flow
Vendor Process:
.1.Sets availability status.
.2.Defines menu and working hours.
.3.Accepts or rejects orders.
.4.Receives real-time notifications.
Customer Process:
.1.Locates available vendors.
.2.Places orders.
.3.Receives real-time updates on vendor status.
3.2 Information Flow
(Flowchart to be included)
Order Flow:
o Customer requests -> Vendor receives order -> Vendor accepts/rejects -
> Customer notified.
Vendor Status Flow:
o Vendor updates status -> Customers receive real-time updates.
Authentication Flow:
4
o OAuth-based login -> Access token validation -> Role-based access
control enforced.
4. API Catalogue
API Name Endpoint Method Description
Login /api/auth/ POST Authenticates a user and returns JWT
Get /api/vendors GET Retrieves list of available vendors
Place Order /api/orders POST Places an order for a customer
Order /api/orders/ GET Fetches the status of an order
(Full API catalog to be detailed separately)
5. Data Design
5.1 Data Model
(ER Diagram to be included)
Users Table: Stores customer and vendor profiles.
Orders Table: Tracks order status, timestamps, and related customer/vendor.
Vendors Table: Manages vendor details, menu, and working hours.
5.2 Data Access Mechanism
REST APIs handle data access using PostgreSQL queries.
WebSockets ensure real-time data updates.
5.3 Data Retention Policies
User and vendor data retained indefinitely unless deleted by the user.
Order history retained for 6 months.
Log files stored for 90 days.
5.4 Data Migration
5
PostgreSQL schema versioning will be managed using Liquibase or Flyway.
6. Interfaces
Google Maps API: Retrieves real-time location data for vendors and customers.
WebSockets: Enables instant vendor status updates and order tracking.
AWS Services: Provides hosting (EC2), database (RDS), and load balancing (ELB).
7. Non-Functional Requirements
7.1 Security Aspects
Authentication: OAuth with JWT-based authentication.
Authorization: Role-Based Access Control (RBAC) for customers and vendors.
Data Encryption: HTTPS/TLS for secure data transmission.
API Security:
o JWT tokens for authentication.
o SQL injection prevention.
o CSRF protection for API requests.
7.2 Performance Aspects
Scalability:
o EC2 instances can be upgraded as needed.
o WebSockets ensure efficient real-time updates.
Rate Limiting: Configured via Nginx to prevent API abuse.
Caching:
6
o Vendor data cached at the service level.
o Database indexes optimized for search queries.
8. Error Handling & Logging Strategy
Application Logs: Stored in AWS CloudWatch for debugging.
Error Handling Mechanism:
o API errors return appropriate HTTP status codes.
o Critical failures trigger alerts and logs.
o Retry mechanisms for failed WebSocket connections.
9. Deployment Strategy
CI/CD: Manual deployments (no automation pipelines).
Downtime: Required during deployment (no blue-green strategy).
Environments: Single production environment.
App Distribution: Manual deployment to Google Play Store & Apple App Store.
10. Future Enhancements
Implement automated CI/CD pipelines.
Enable auto-scaling for future traffic growth.
Support additional notification channels (SMS, email).
Introduce AI-based vendor recommendations.
11. References
(To be included)
7
Architectural Design Principles.
API documentation.
Database Schema Design.
8

Design_Document_design.document template.docx

  • 1.
    <> Project: Design_Document VersionNO. - 1.00 Authorised by - 1
  • 2.
    Confidentiality Agreement <Insert confidentialityclause and copy Right> Revision History Version Date Author Reviewer Approver Comments 1. Introduction 1.1 Scope of the Document This document provides a high-level architectural design of the Ice Cream Truck App, defining its structure, components, and interactions. It serves as a blueprint for development, outlining key technical decisions, system behavior, and design principles. 1.2 Intended Audience Development Team Solution Architects 2
  • 3.
    Product Owners Quality AssuranceTeam DevOps Engineers Business Stakeholders 1.3 System Overview The Ice Cream Truck App is a mobile-based solution that allows customers to locate and order from nearby ice cream vendors in real-time. Vendors can update their availability, manage their menu, and accept or reject orders. The system is designed for scalability, security, and real-time responsiveness. Sample content: 2. System Design 2.1 Architecture Overview The system follows a monolithic backend architecture using Node.js with Express, deployed on AWS EC2. The database is hosted on PostgreSQL (AWS RDS). Real- time updates are handled via WebSockets, and load balancing is managed through AWS ELB (Elastic Load Balancer) with Route 53. 2.2 Key Components Frontend: React Native (Expo) mobile application. Backend: Node.js Express server hosted on AWS EC2. Database: PostgreSQL on AWS RDS. Caching: Service-level caching enabled for high-volume vendor data. Real-time Updates: Implemented using WebSockets. Load Balancer: AWS ELB connected to Route 53. 3
  • 4.
    Rate Limiting: Configuredvia Nginx. (Architecture Diagram to be included) 3. Application Design 3.1 Process Flow Vendor Process: .1.Sets availability status. .2.Defines menu and working hours. .3.Accepts or rejects orders. .4.Receives real-time notifications. Customer Process: .1.Locates available vendors. .2.Places orders. .3.Receives real-time updates on vendor status. 3.2 Information Flow (Flowchart to be included) Order Flow: o Customer requests -> Vendor receives order -> Vendor accepts/rejects - > Customer notified. Vendor Status Flow: o Vendor updates status -> Customers receive real-time updates. Authentication Flow: 4
  • 5.
    o OAuth-based login-> Access token validation -> Role-based access control enforced. 4. API Catalogue API Name Endpoint Method Description Login /api/auth/ POST Authenticates a user and returns JWT Get /api/vendors GET Retrieves list of available vendors Place Order /api/orders POST Places an order for a customer Order /api/orders/ GET Fetches the status of an order (Full API catalog to be detailed separately) 5. Data Design 5.1 Data Model (ER Diagram to be included) Users Table: Stores customer and vendor profiles. Orders Table: Tracks order status, timestamps, and related customer/vendor. Vendors Table: Manages vendor details, menu, and working hours. 5.2 Data Access Mechanism REST APIs handle data access using PostgreSQL queries. WebSockets ensure real-time data updates. 5.3 Data Retention Policies User and vendor data retained indefinitely unless deleted by the user. Order history retained for 6 months. Log files stored for 90 days. 5.4 Data Migration 5
  • 6.
    PostgreSQL schema versioningwill be managed using Liquibase or Flyway. 6. Interfaces Google Maps API: Retrieves real-time location data for vendors and customers. WebSockets: Enables instant vendor status updates and order tracking. AWS Services: Provides hosting (EC2), database (RDS), and load balancing (ELB). 7. Non-Functional Requirements 7.1 Security Aspects Authentication: OAuth with JWT-based authentication. Authorization: Role-Based Access Control (RBAC) for customers and vendors. Data Encryption: HTTPS/TLS for secure data transmission. API Security: o JWT tokens for authentication. o SQL injection prevention. o CSRF protection for API requests. 7.2 Performance Aspects Scalability: o EC2 instances can be upgraded as needed. o WebSockets ensure efficient real-time updates. Rate Limiting: Configured via Nginx to prevent API abuse. Caching: 6
  • 7.
    o Vendor datacached at the service level. o Database indexes optimized for search queries. 8. Error Handling & Logging Strategy Application Logs: Stored in AWS CloudWatch for debugging. Error Handling Mechanism: o API errors return appropriate HTTP status codes. o Critical failures trigger alerts and logs. o Retry mechanisms for failed WebSocket connections. 9. Deployment Strategy CI/CD: Manual deployments (no automation pipelines). Downtime: Required during deployment (no blue-green strategy). Environments: Single production environment. App Distribution: Manual deployment to Google Play Store & Apple App Store. 10. Future Enhancements Implement automated CI/CD pipelines. Enable auto-scaling for future traffic growth. Support additional notification channels (SMS, email). Introduce AI-based vendor recommendations. 11. References (To be included) 7
  • 8.
    Architectural Design Principles. APIdocumentation. Database Schema Design. 8