Section 4

Core Components

The platform consists of six containerized components plus external managed services. Five containers run within client infrastructure; one external service (blob storage) is accessed via S3-compatible SDK calls.

C1 — Web Node

Web Node

Responsibilities

›Authentication and session management
›Meeting dashboard and full-text search
›Query interface for intelligence retrieval
›Admin controls and configuration
›API endpoints for external integrations

Technology

Next.js (TypeScript) with a React frontend. Handles all user-facing routes and server-side API logic in a single deployable container.

The Next.js stack is the recommended choice for its cohesive full-stack model, but the backend API contract is framework-agnostic — the frontend can be adapted to other stacks without rearchitecting the rest of the platform.

C2 — Job Runner

Job Runner

The async processing engine — handles all heavy lifting outside the request/response cycle. Every compute-intensive job runs here, keeping the Web Node responsive.

Responsibilities

›Audio ingestion from Meeting Bots
›Transcription orchestration
›Speaker diarization
›Embedding generation
›Scheduled background agents
›Intelligence layer aggregation (L1/L2/L3)

Technology

Node.js + TypeScript with BullMQ for job queue management, backed by Redis (C4). BullMQ provides durable queues, retry logic, concurrency controls, and job progress tracking — all critical for reliable async processing at scale.

C3 — Vector Database (Qdrant)

Qdrant

Why Qdrant

›Written in Rust — high throughput, low memory overhead
›Open source (Apache 2.0) — no vendor lock-in
›Purpose-built for vector search with rich metadata filtering
›Single Docker container with TypeScript SDK

Key Insight

Metadata filtering is integrated directly into the search pass — not applied as post-processing. This means filtered queries (e.g., "only meetings from client X in Q4") do not degrade in performance as the corpus grows. The query complexity stays constant regardless of corpus size when filters are applied at index time.

Collection Schema — meeting_chunks

Collection: meeting_chunks
  - id:               uuid
  - meeting_id:       uuid
  - meeting_stream:   enum (solution_architecture | pmo | sales_interlock | other)
  - speaker:          string
  - timestamp_start:  float
  - timestamp_end:    float
  - text:             string
  - embedding:        vector[dimensions dependent on model]
  - metadata: {
      client:         string,
      participants:   string[],
      meeting_date:   datetime,
      tags:           string[]
    }

C4 — Redis

Redis

Responsibilities

›BullMQ backing store (job queues for C2)
›Session caching for the Web Node
›Pub/Sub for real-time event routing
›Rate limiting on API endpoints
›Query result caching

Deployment

Redis 7+ via Alpine Docker image with a persisted volume. Minimal footprint — Redis is extremely memory-efficient at this scale and requires no tuning for MVP workloads.

C5 — PostgreSQL

PostgreSQL

Responsibilities

›User accounts and authentication records
›Meeting metadata (titles, dates, participants)
›Agent configurations and schedules
›RBAC policies and access control

Deployment

PostgreSQL 16+ with a persisted volume. Handles all structured relational data — the source of truth for anything that isn't a vector embedding or a binary asset.

S3-Compatible Object Storage

Blob Storage

External

Managed external service — not a container in the client stack.

Stores

›Audio recordings (WebM format from Meeting Bots)
›Raw transcript JSON
›Generated intelligence reports

Provider Options

›Cloudflare R2 — recommended; no egress fees
›AWS S3
›GCP Cloud Storage

All providers accessed via S3-compatible SDK calls — switching providers requires only a config change.

Performance Profiles

Most components require no sizing attention at MVP scale. Only the Vector Database grows with the corpus and may need tuning over time.

Web Node + PostgreSQL + Redis — Negligible

These three components share resources and run comfortably on default configurations. No tuning required at MVP scale. 2 vCPU, 4GB RAM total is sufficient for the combined group.

Job Runner

Profile 1

2–4 vCPU, 4–8GB RAM

›Bursty, mostly I/O-bound (waiting on API responses)
›Scales vertically with concurrency settings
›CPU spikes during transcription/embedding batches

Vector Database

Profile 2

4 vCPU, 16GB RAM

›The only component where sizing matters as corpus grows
›Holds the semantic index in memory for fast retrieval
›The one component that may need tuning post-MVP

Meeting Bots

Profile 3

2 vCPU, 2GB RAM per instance

›Stateless, horizontally scalable
›One container per concurrent meeting
›Scale with additional replicas

Summary

Group	Components	Scaling Driver	MVP Allocation
Negligible	Web Node, PostgreSQL, Redis	None	2 vCPU, 4GB RAM (shared)
Profile 1	Job Runner	Meeting volume, agent complexity	2–4 vCPU, 4–8GB RAM
Profile 2	Vector DB	Corpus size	4 vCPU, 16GB RAM
Profile 3	Meeting Bots (× N)	Concurrent meetings	2 vCPU, 2GB RAM each

Total for MVP fits comfortably on a single mid-range server or a small Kubernetes cluster.