> ## Documentation Index
> Fetch the complete documentation index at: https://poolerz.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# System Architecture
> The system architecture of Poolerz.
Our application is structured using a **3-layer architecture**, two of which are enveloped by our web application. This structure provides **flexible development** and easier building through technologies such as **React and TypeScript**. We chose this structure to ensure a **smooth transition** during project turnover, allowing future teams to easily understand the design and layer separation.
The **static and dynamic architectures** outlined below further explore the interactions within our system.
## Rationale
Our architecture was planned to **efficiently build a dynamic application**. By maintaining a **clear separation** between different architectural levels, we effectively outlined the tasks and processes each section would manage during runtime.
We utilize **Google Sign-On** via **OAuth 2.0** for user authentication. This approach leverages Google’s **robust security infrastructure**, including multi-factor authentication. As a result, we do not store sensitive password information, reducing vulnerabilities related to **password reuse** and **database breaches**.
## Static Architecture
Our **static system architecture** was designed to develop a **responsive interface** and an efficient **full-stack web application**. We clearly delineate between the **front-end, back-end, and database layers** to represent their interactions.
**Figure 1.1 - Static System Diagram**\\
### **Key Components:**
* **Web Application:** The central part of our system, encompassing both **front-end** and **back-end** processes.
* **Frontend (User Interaction Layer):** Built using **React, TypeScript, and HTML**, ensuring an intuitive and seamless desktop application.
* **Backend (Business Logic Layer):**
* Uses **Node.js** to handle server-side logic.
* Interacts with the **database** to store user information.
* Executes the **optimization algorithm** to manage carpool groupings and update the frontend accordingly.
* **Database Layer:**
* Uses **MongoDB** to store and track **user profiles**, **carpool organizations**, and **group data**.
* Maintains persistent storage and updates user data dynamically.
## Dynamic Architecture
Our **dynamic system architecture** represents a real-world user scenario for **creating and managing a Carpool Group**. A **system sequence diagram** illustrates how different components interact to create a **seamless user experience**.
**Figure 1.2 - Dynamic System Diagram**
### **User Scenario: Carpool Group Creation**
1. **User initiates group creation:**
* The **User Interaction layer** presents the interface for front-end interactions.
* The **backend components** are prepared for handling user requests.
2. **User requests to view or create a carpool:**
* The **frontend** collects user input and forwards it to the **backend**.
* The **backend retrieves user data and carpool information** from the **database**.
3. **Data retrieval & optimization:**
* The **Business Logic layer** fetches data from the **database**.
* The backend queries stored carpools and members, executing **optimization algorithms** to sort users into driving groups.
4. **Interface update:**
* Once the **backend** processes the request, data is returned to the **frontend**.
* The **User Interaction layer** updates the interface with the latest carpool group details.
5. **Database maintenance:**
* The **MongoDB database** continuously stores and updates user data.
* It fetches and returns information such as **location** and **availability** for all carpool members, ensuring the **optimizer functions effectively**.
This structured system ensures **scalability, efficiency, and security**, creating a smooth user experience for managing carpooling logistics.