3. 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
Product Owners
Quality Assurance Team
DevOps Engineers
Business Stakeholders
1.3 System Overview
3
4. 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.
Rate Limiting: Configured via Nginx.
(Architecture Diagram to be included)
3. Application Design
3.1 Process Flow
4
5. 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:
o OAuth-based login -> Access token validation -> Role-based access control
enforced.
4. API Catalogue
API Name Endpoint Method Description
Login /api/auth/login POST Authenticates a user and returns JWT token
Get Vendors /api/vendors GET Retrieves list of available vendors
Place Order /api/orders POST Places an order for a customer
Order Status /api/orders/{id} GET Fetches the status of an order
(Full API catalog to be detailed separately)
5
6. 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
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
6
7. 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:
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
