Skip to content

Jansiz/Encompass

Repository files navigation

ENCOMPASS

check out Encompass: aiencompass.com

System Architecture Prototype Overview


encompass-prototype-systemdesign

This document provides a detailed description of the system architecture for our application, which involves user interaction, data processing using a Large Language Model (LLM), video generation LLM, and efficient data storage.

1. Frontend

Components:

  • Load Balancer: The entry point for all user requests. It distributes incoming traffic across multiple frontend servers to ensure no single server is overwhelmed, enhancing availability and scalability.
  • Frontend Servers: These servers handle user-facing operations such as logging in, submitting questionnaires, and interacting with the user dashboard. They route requests to the appropriate backend services for further processing.

2. Backend

Components:

  • User Authentication Service: Manages user login processes and session management. It ensures secure access to the application by verifying user credentials and maintaining session states.
  • Questionnaire Service: Handles the submission and processing of user responses to the questionnaire. Once data is collected, it is stored in the sharded database, linked to the corresponding user ID.
  • LLM API Load Balancer: Distributes requests for script generation across multiple instances of the LLM service. This ensures that the system can handle a high volume of requests simultaneously, distributing the computational load evenly.
  • LLM Services: These services generate personalized storytelling scripts based on user responses. The load balancer ensures that requests are efficiently distributed across multiple LLM service instances.
  • Video API Load Balancer: Manages the distribution of video generation tasks across multiple instances of the video generative service. This load balancer is crucial for handling the resource-intensive task of video creation.
  • Video Generative Services: These services generate videos from the scripts produced by the LLM. The generated videos are large and stored in cloud storage, with references kept in the main database.

3. Main Database (Sharded by User ID)

Components:

  • Sharded Database: The main database is horizontally partitioned (sharded) based on user IDs. This means all data related to a specific user (including user information, questionnaire answers, scripts, and video references) is stored in the same shard, optimizing performance and simplifying data access.
  • Shard 1: Manages data for user IDs in the range 1-1000.
  • Shard 2: Manages data for user IDs in the range 1001-2000.
  • Shard N: Extends this structure to cover additional ranges of user IDs as the user base grows.
  • Replication: Each shard is replicated to ensure high availability and fault tolerance. Replication helps maintain data consistency and provides a backup in case of shard failure.

4. Cloud Storage (AWS S3 - not decided)

Components:

  • Storage Service (AWS S3): This service is responsible for storing large video files generated by the video generative service. AWS S3 is chosen for its scalability, durability, and cost-effectiveness.
  • Video Files: The actual video content generated from the LLM scripts.
  • Database Reference: References to these video files are stored in the main database shards, ensuring that all related user data can be easily retrieved and displayed.

5. User Interface (User Dashboard)

Components:

  • User Dashboard: The central interface where users can view their questionnaire responses, generated scripts, and videos. The dashboard retrieves data from the user’s specific shard in the database and video files from AWS S3.

Data Flow Overview

  • User Interaction: Users access the system via the frontend, where they can log in, submit their questionnaire responses, and view their personalized content.
  • Data Processing: User data is processed by the backend services. The questionnaire service stores responses in the sharded database. The LLM service generates scripts, which are also stored in the database. The video generative service creates videos from these scripts, stored in AWS S3 with references in the database.
  • Data Storage: All data is stored in the sharded database, ensuring efficient access based on user ID. Video content is stored in AWS S3 to handle the large file sizes efficiently.
  • Data Retrieval: The user dashboard pulls data from both the sharded database and AWS S3, presenting it to the user in a seamless, integrated interface.

Scalability and Fault Tolerance

  • Load Balancing: Both the frontend and backend services use load balancers to ensure that incoming requests are distributed efficiently across available servers. This setup improves system reliability and ensures that services can scale to handle increased traffic.
  • Sharding: The database is sharded by user ID, which allows for horizontal scaling. As the number of users grows, new shards can be added to distribute the load.
  • Replication: Each database shard is replicated to provide redundancy and improve fault tolerance. If a primary shard fails, its replica can take over, minimizing downtime.

About

Who Would You Be If You Were All That You Could Be?

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published