> ## Documentation Index
> Fetch the complete documentation index at: https://prismeai-docs-next.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Example of Platform Sizing

> Resource recommendations for self-hosted deployments

<Info>
  This sizing depends on your specific use case, whether it's full automation or chat mode. We strongly recommend conducting your own load testing tailored to your specific infrastructure and use cases.
</Info>

## Target Performance Metrics

<CardGroup cols="3">
  <Card title="User Interactions">
    **4-10 per user**

    Average number of interactions each user makes with the platform
  </Card>

  <Card title="First Token Response">
    **478ms (P95)**

    Time to first token from LLM API (using OpenAI as reference)
  </Card>

  <Card title="Concurrent Users">
    **100 new users/second**

    Platform should handle 100 new users each second under peak load
  </Card>
</CardGroup>

## Infrastructure Components

### Kubernetes Cluster

**Node Configuration:** 5 nodes with 8GB RAM and 4 vCPU each

### Storage Systems

<Tabs>
  <Tab title="EFS">
    **Capacity:** 50GB Elastic File System for shared storage

    **Configuration:** Can be shared between different environments or isolated for each
  </Tab>

  <Tab title="Object Storage">
    **Bucket Structure:** Environment-based separation

    * 1 "models" bucket per environment
    * 1 "uploads" bucket per environment
    * 1 "uploads-public" bucket per environment (behind CDN)
  </Tab>
</Tabs>

### Databases

<Tabs>
  <Tab title="MongoDB/PostgreSQL">
    **Data Types:** RBAC permissions, users, application data

    **Configuration:**

    * 3 nodes in replica set
    * 2GB RAM and 2 vCPU per node
    * 1,000 IOPS

    **Disk Space:** 10GB total storage requirement

    **Environment Separation:**

    * 1 "permissions" database per environment
    * 1 "users" database per environment
    * 1 "collections" database per environment

    **Version:**

    * MongoDB version 6 with path to version 7
    * Or PostgreSQL >=10

    <Info>
      The cluster can be shared across environments with proper database separation.
    </Info>
  </Tab>

  <Tab title="Redis Cache & Broker">
    **Data Types:** Real-time EDA streams, permission cache, OIDC sessions, rate limits, application cache

    **Configuration:**

    * 1 master and 2 replicas
    * 3GB RAM and 2 vCPU per node

    **Environment Separation:** 1 cluster per environment recommended

    **Version:** Redis version 5 or higher
  </Tab>

  <Tab title="Redis Crawler">
    **Data Types:** Crawl queue, metadata of known documents, search engine configurations

    **Configuration:**

    * 1 master and 2 replicas
    * 2GB RAM and 2 vCPU per node

    **Environment Separation:** 1 database per environment

    **Version:** Redis version 5 or higher

    **Scaling Example:** 100,000 documents → 600MB RAM

    <Info>
      The cluster can be shared across environments with proper database separation.
    </Info>
  </Tab>

  <Tab title="Elasticsearch/OpenSearch">
    **Data Types:** Persisted EDA events for traceability and statistics calculations, text content of crawled documents

    **Configuration:**

    * 3 nodes
    * 8GB RAM and 4 vCPU per node

    **Disk Space:** 400GB per node (NVMe or SSD storage recommended)

    **Version:** Elasticsearch/OpenSearch version 8 or higher
  </Tab>

  <Tab title="Vector Database">
    **Implementation:** Redis Stack (Redis with vector search capabilities)

    **Data Types:** Text chunks accompanied by their vector embeddings

    **Configuration:**

    * 1 master and 2 replicas
    * 5GB RAM and 2 vCPU per node

    **Environment Separation:** 1 cluster per environment recommended

    **Version:** Redis version 5 or higher with SEARCH and JSON modules

    **Scaling Example:** 100,000 chunks from 20,000 documents requires approximately 2.6GB RAM
  </Tab>
</Tabs>

## Scaling Considerations

<Accordion title="Horizontal vs. Vertical Scaling">
  When planning your infrastructure, consider these scaling approaches:

  * **Horizontal Scaling:** Add more nodes to distribute load. Recommended for Kubernetes nodes and database replicas.
  * **Vertical Scaling:** Increase resources (RAM, CPU) on existing nodes. Useful for temporary peaks or when hitting connection limits.

  For most production deployments, we recommend a combination of both approaches with an emphasis on horizontal scaling for better resilience.
</Accordion>

<Accordion title="Resource Allocation Strategy">
  When allocating resources across components:

  1. Start with our baseline recommendations
  2. Monitor resource utilization during testing
  3. Identify bottlenecks (usually memory or disk I/O)
  4. Scale the constrained resources first before adding more nodes

  Vector databases and Elasticsearch typically benefit most from additional memory, while Redis is often constrained by CPU.
</Accordion>

<Accordion title="Environment Isolation">
  For multi-environment deployments:

  * **Development:** Can share infrastructure with minimal isolation
  * **Staging:** Should mimic production but can use smaller resources
  * **Production:** Requires dedicated resources and stricter isolation

  We recommend full cluster-level isolation for production, while development and staging can share some database clusters with proper database-level separation.
</Accordion>

## Monitoring Recommendations

We recommend monitoring the following metrics to ensure optimal performance:

<CardGroup cols="3">
  <Card title="System Metrics" icon="server">
    * CPU utilization
    * Memory usage
    * Disk I/O and latency
    * Network throughput
  </Card>

  <Card title="Application Metrics" icon="gauge">
    * Request latency
    * Error rates
    * Concurrent users
    * Queue lengths
  </Card>

  <Card title="Database Metrics" icon="database">
    * Query performance
    * Connection pool usage
    * Index efficiency
    * Replication lag
  </Card>
</CardGroup>

<Info>
  These sizing recommendations provide a starting point, but real-world performance may vary. Always conduct load testing with scenarios that reflect your actual usage patterns.
</Info>