2. 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
3. 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
4. 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
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 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
7. 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
