​
Overview

The Sigma application is a set of Docker Containers which can be deployed on any infra and for any scale.

​
System Architecture

Sigma Architecture

​
Core Components

​
Application Layer

  • Frontend web client: Next.js-based web application providing the user interface for the Sigma platform
  • API Server: Python FastAPI web server to handle business logic and requests
  • Background Workers: Python workers to handle async jobs like fetching document updates, etc.

​
Data Layer

  • Relational Database: Postgres database to store application data, user sessions, and system state
  • Vector Database: Vespa keyword search engine + vector store for retrieving context for queries
  • In Memory Cache: Redis, used to optimize performance
  • File Store: MinIO blob store for user uploaded files and documents pulled from connectors

​
Infrastructure Layer

  • Request Router: Nginx reverse proxy for load balancing and request routing

​
Component Replacements

Some components of the Sigma stack are easily replaceable while others are not. MinIO can be replaced with S3 or any similar object storage service. The file store interface is abstracted to make this straightforward. Redis can be replaced with a managed Redis service like AWS ElastiCache. Other in-memory caches could work but would require code changes. Postgres can be replaced with a managed Postgres service such as AWS RDS. It is much more challenging and not advised to switch to a different relational DB due to language specific features and optimizations. Vespa can be replaced with multi-node Vespa deployment (typically not necessary) or Vespa Cloud. Vespa is tightly integrated with the context retrieval functionalities and replacing it would require significant development effort to maintain the same functionality. Nginx can be removed and replaced with your own routing proxy.