Chapter 11: Hardware & Scaling 🟑 BETA

This chapter covers hardware requirements and horizontal scaling strategies for General Bots.

Overview

General Bots is designed from the ground up to scale horizontally. The architecture supports:

  • Multi-tenancy: Complete isolation between organizations
  • Regional sharding: Data locality for compliance and performance
  • Database partitioning: Efficient handling of high-volume tables
  • Stateless services: Easy horizontal pod autoscaling

Chapter Contents

Key Concepts

Tenant Isolation

Every piece of data in General Bots is associated with a tenant_id. This enables:

  1. Complete data isolation between organizations
  2. Per-tenant resource limits and quotas
  3. Tenant-specific configurations
  4. Easy data export/deletion for compliance

Shard Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                      Load Balancer                          β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                          β”‚
        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β”‚                 β”‚                 β”‚
        β–Ό                 β–Ό                 β–Ό
   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
   β”‚ Region  β”‚       β”‚ Region  β”‚       β”‚ Region  β”‚
   β”‚   USA   β”‚       β”‚   EUR   β”‚       β”‚   APAC  β”‚
   β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜       β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜       β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
        β”‚                 β”‚                 β”‚
   β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”       β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”       β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”
   β”‚ Shard 1 β”‚       β”‚ Shard 2 β”‚       β”‚ Shard 3 β”‚
   β”‚ Shard 4 β”‚       β”‚ Shard 5 β”‚       β”‚ Shard 6 β”‚
   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Database Design Principles

  1. SMALLINT enums instead of VARCHAR for domain values (2 bytes vs 20+ bytes)
  2. Partitioned tables for high-volume data (messages, sessions, analytics)
  3. Composite primary keys including shard_id for distributed queries
  4. Snowflake-like IDs for globally unique, time-sortable identifiers

When to Scale

UsersSessions/dayMessages/dayRecommended Setup
< 10K< 100K< 1MSingle node
10K-100K100K-1M1M-10M2-3 nodes, single region
100K-1M1M-10M10M-100MMulti-node, consider sharding
1M-10M10M-100M100M-1BRegional shards
> 10M> 100M> 1BGlobal shards with Citus/CockroachDB

Quick Start

To enable sharding in your deployment:

  1. Configure shard mapping in shard_config table
  2. Set SHARD_ID environment variable per instance
  3. Deploy region-specific instances
  4. Configure load balancer routing rules

See Sharding Architecture for detailed setup instructions.