Skip to content

sameer2210/SpandaVidya-ChatBox

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

19 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

SpandaVidyaAi β€” Ayurvedic AI Chat Assistant 🌿 Project Overview

SpandaVidyaAi is a modern AI-powered chat application that responds like an Ayurvedic doctor (Vaidya). It blends classical Ayurvedic knowledge with Google Gemini AI to provide natural, context-aware wellness guidance through a clean, minimal chat interface.

React Gemini

The project focuses on:

Authentic Ayurvedic tone and terminology Fast, lightweight frontend Modular, scalable architecture Secure AI integration

🧠 Core Philosophy

Ancient wisdom. Modern intelligence.

SpandaVidyaAi is designed to simulate the consultation style of an Ayurvedic practitionerβ€”focusing on Doshas (Vata, Pitta, Kapha), lifestyle balance, and holistic well-being rather than symptom-only answers.

πŸš€ Features

🧘 Ayurvedic-style AI responses (Vaidya tone) πŸ’¬ Minimal, distraction-free chat UI ⚑ Fast frontend powered by Vite 🧩 Modular React component structure πŸ” Centralized Gemini AI service layer ♻️ Easy to extend (profiles, history, auth)

πŸ—οΈ Project Architecture SpandaVidyaAi/ β”œβ”€β”€ index.html # App entry HTML β”œβ”€β”€ package.json β”œβ”€β”€ vite.config.ts β”œβ”€β”€ .env.local # Gemini API key (not committed) └── src/ β”œβ”€β”€ index.tsx # React entry point β”œβ”€β”€ App.tsx # Root component β”œβ”€β”€ components/ # UI components β”‚ β”œβ”€β”€ ChatInterface.tsx β”‚ β”œβ”€β”€ MessageBubble.tsx β”‚ β”œβ”€β”€ Input.tsx β”‚ β”œβ”€β”€ Button.tsx β”‚ └── Sidebar.tsx β”œβ”€β”€ services/ β”‚ └── geminiService.ts # Gemini AI integration β”œβ”€β”€ types.ts # Shared TypeScript types β”œβ”€β”€ constants.ts # App constants └── metadata.json # App metadata

🧰 Technology Stack Frontend

React + TypeScript Vite (fast dev & build tool) Modern component-based UI AI Google Gemini API Prompt-engineered for Ayurvedic responses Runtime Node.js

npm

πŸ”„ How It Works

  1. User Interaction Flow User inputs query β†’ Chat UI β†’ Gemini Service β†’ AI response β†’ Message bubble

  2. AI Response Strategy User question ↓ System prompt (Ayurvedic doctor role) ↓ Gemini AI reasoning ↓ Structured, calm, Vaidya-style reply

πŸ” Environment Setup

Create a .env.local file in the project root:

GEMINI_API_KEY=your_gemini_api_key_here

⚠️ Security Note If exposing API calls in the browser, follow Vite conventions (VITE_ prefix) or proxy requests through a backend for production.

πŸš€ Getting Started Prerequisites

Node.js 16+ (LTS recommended)

npm

Installation npm install

Run Development Server npm run dev

Open: πŸ‘‰ http://localhost:5173

πŸ“œ Available Scripts

npm run dev β€” start development server npm run build β€” production build npm run preview β€” preview production build

🌱 Ayurvedic AI Tone Rules (Design Principle)

SpandaVidyaAi responses are designed to: Avoid medical diagnosis claims Use calming, advisory language Reference Doshas & lifestyle balance Encourage holistic well-being

Maintain respectful, traditional tone

πŸ”’ Best Practices

Never commit .env.local Keep AI logic centralized in geminiService.ts Maintain small, reusable UI components Extend via prompts, not hard-coded logic

πŸ›£οΈ Future Enhancements

User profiles & Dosha history Conversation persistence Multi-language support Auth + secure backend proxy Ayurvedic diet & routine modules Mobile-first UI refinement

🀝 Contributing

Fork the repository Create a feature branch Keep commits clean and focused Submit a PR with a clear description

πŸ“„ License

No license included yet. Add MIT or Apache 2.0 before public distribution.

πŸ‘¨β€πŸ’» Developer

Harsh Bairagi

Full Stack Developer (MERN)

NOW UPGRADE IT WITH 10k USERS

  1. Product Definition Layer What exactly you are building A multi-tenant, real-time AI chat platform with:

User auth + teams/workspaces

Conversation history + memory

Streaming AI responses

Tool/function calling (optional)

RAG (retrieval-augmented generation) over user/org data

Observability, billing, governance, abuse prevention

Enterprise-grade reliability and compliance posture

Core components Web/mobile client

Edge/CDN + WAF

API Gateway + auth

Chat session service

AI Orchestration service

LLM provider adapters (OpenAI/Anthropic/self-host)

RAG pipeline (ingest/chunk/embed/retrieve/rerank)

Vector DB + primary OLTP DB + Redis cache

Event bus/queue

Monitoring/logging/tracing

CI/CD + IaC + Kubernetes control plane

Functional requirements User signup/login/social/SSO

Create conversations, send messages, stream responses

Multi-model selection (quality/latency/cost tiers)

File upload + indexing + retrieval

Conversation search

Admin controls (quota, moderation, audit logs)

Billing and usage metering

Retry/resume partial responses

APIs + SDKs + webhooks

Non-functional requirements High availability (regional failure tolerance)

Strong security (zero trust, encryption, tenant isolation)

Elastic scalability

Low latency for first token + continuous stream

Cost controls per tenant/model/use-case

Full observability + SLOs + error budgets

Compliance-ready foundation (SOC2, GDPR, HIPAA-ready patterns)

Performance targets (realistic production SLOs) P50 first-token latency: < 700ms (small prompt, cached retrieval)

P95 first-token latency: < 2.5s

P99 API latency (non-AI endpoints): < 200ms

Streaming continuity: chunk gap < 300ms P95

Availability: 99.95% (single region), 99.99% (multi-region active-active)

Concurrency target: architect for 1M simultaneous websocket/SSE sessions

Durability: RPO < 5 min, RTO < 30 min (regional DR)

  1. High-Level System Architecture System diagram (textual) Client -> CDN/WAF -> API Gateway -> (Auth, Chat API) -> AI Orchestrator -> LLM Adapter(s) AI Orchestrator -> RAG Service -> Vector DB + Object Store + Metadata DB All services -> Redis/Queue -> DBs -> Observability stack

Layer breakdown Edge Layer: CDN, WAF, bot filtering, TLS termination

API Layer: Gateway, auth verification, rate limiting, request shaping

Application Layer: chat state, orchestration, retrieval, policy engine

Model Layer: provider abstraction + inference backend

Data Layer: Postgres/MySQL, vector DB, Redis, blob storage

Async Layer: Kafka/PubSub/SQS for ingestion, analytics, retries

Control Plane: CI/CD, config, feature flags, secrets, autoscaling

Observability/Security Layer: logs/metrics/traces/SIEM/alerts

Request flow (step-by-step) Client opens session (SSE/WebSocket).

Edge validates TLS, WAF checks, forwards to gateway.

Gateway authenticates JWT/session + applies user/org quotas.

Chat service stores user message (append-only event + materialized view).

AI Orchestrator:

applies policy (prompt safety, budget, tenant limits)

retrieves context (RAG)

builds model prompt

routes to selected LLM backend

LLM tokens stream back through orchestrator to client.

Final response persisted + usage metrics emitted.

Async jobs update analytics/billing/search index.

Scaling at each layer Edge: global CDN PoPs + anycast

API: stateless pods horizontally scaled

Chat state: DB sharding + Redis for hot session state

Orchestrator: worker pool autoscaling by in-flight token streams

Vector retrieval: read replicas + partitioned indexes

Queues: partition/topic scaling with consumer groups

Monitoring: cardinality control to avoid observability collapse

  1. Deep Technical Architecture (Component by Component) I’ll keep each component in the same format.

A) Frontend Purpose: UX, streaming display, retries, offline behavior

Internal design: React/Next.js, SSE preferred for one-way token streaming; WebSocket for tool events

Scaling: CDN cache static assets; edge rendering where useful

Failure scenarios: stream disconnect, duplicated chunks, stale auth token

Edge cases: partial markdown tokens, long conversation DOM bloat

Security risks: XSS via rendered model output

Bottlenecks: client re-render storms during token stream

Optimization: token batching (50–100ms), virtualized chat list

Alternatives: native app + gRPC streaming

B) API Gateway Purpose: central ingress, auth check, traffic governance

Internal design: Envoy/Kong/NGINX + OPA policy plugin

Scaling: stateless replicas + HPA on RPS and CPU

Failures: auth provider timeout, upstream circuit open

Edge cases: head-of-line blocking during spikes

Security: header spoofing, JWT algorithm confusion

Bottlenecks: TLS handshake overhead

Optimization: keep-alive, HTTP/2, connection pooling

Alternatives: Cloudflare/AWS API Gateway managed edge

C) Authentication system Purpose: identity + session trust

Design: OIDC provider (Auth0/Keycloak/Cognito), short-lived JWT + refresh token rotation

Scaling: token verification locally via JWKS cache

Failures: IdP outage

Edge cases: clock skew invalidating tokens

Security: refresh token theft

Optimization: local claims cache + introspection fallback

Alternatives: passkeys + enterprise SAML SSO

D) Chat service Purpose: conversation lifecycle and persistence

Design: append-only message events + denormalized conversation table

Scaling: partition by tenant_id + conversation_id hash

Failures: write hot shard

Edge cases: out-of-order writes from retries

Security: IDOR (cross-tenant chat access)

Bottlenecks: write amplification with sync indexing

Optimization: async indexing + idempotency keys

Alternatives: event-sourced stream store

E) AI orchestration layer Purpose: routing, policies, prompt composition, tools

Design: deterministic pipeline + policy engine + model router

Scaling: horizontally by active generation count

Failures: stuck tool execution, provider timeout cascade

Edge cases: recursive tool loops

Security: prompt injection, tool misuse

Bottlenecks: synchronous retrieval + reranking latency

Optimization: parallel retrieval + speculative model selection

Alternatives: LangGraph, custom DAG runtime

F) LLM integration Purpose: unified abstraction over providers/models

Design: adapter interface (generate, stream, embeddings, moderation)

Scaling: multi-provider failover + weighted routing

Failures: provider quota exhausted

Edge cases: tokenization differences

Security: sensitive data leakage to third-party API

Bottlenecks: high TTFT on large prompts

Optimization: prompt compaction, prefix caching, response caching

Alternatives: single-provider lock-in (simple, risky)

G) Vector database Purpose: semantic retrieval

Design: hybrid search (BM25 + ANN), metadata filters

Scaling: collection partitioning by tenant/domain

Failures: index rebuild lag

Edge cases: noisy embeddings from OCR docs

Security: tenant filter bypass

Bottlenecks: high-dimensional index memory pressure

Optimization: HNSW tuning, reranker top-k reduction

Alternatives: Pinecone/Weaviate/Qdrant/pgvector

H) Primary database Purpose: source of truth (users, billing, conversations metadata)

Design: Postgres with read replicas + partitioned tables

Scaling: Citus/sharding or Vitess/MySQL horizontal split

Failures: primary failover split-brain

Edge cases: long-running transactions blocking VACUUM

Security: SQL injection, weak row-level isolation

Bottlenecks: write locks on hot rows

Optimization: append patterns, queue heavy jobs

Alternatives: CockroachDB/Spanner-like distributed SQL

I) Caching layer (Redis) Purpose: hot session state, rate counters, token buckets

Design: Redis Cluster + persistence mode based on risk

Scaling: shard by key hash tags

Failures: cache stampede

Edge cases: stale permission cache

Security: exposed Redis endpoint

Bottlenecks: big key scans

Optimization: jittered TTL + request coalescing

Alternatives: KeyDB, Aerospike

J) Queue system Purpose: decouple heavy/slow work

Design: Kafka/PubSub for streams, SQS/Rabbit for jobs

Scaling: partitions + consumer groups

Failures: poison messages

Edge cases: duplicate delivery semantics

Security: unauthorized consumer access

Bottlenecks: partition imbalance

Optimization: DLQ, retry backoff, idempotent consumers

Alternatives: NATS JetStream

K) Logging & monitoring Purpose: detect, debug, optimize

Design: OpenTelemetry traces, Prometheus metrics, Loki/ELK logs

Scaling: sampling + cardinality budgets

Failures: telemetry pipeline overload

Edge cases: missing trace context on async hops

Security: PII in logs

Optimization: structured logs + dynamic sampling

Alternatives: Datadog/New Relic/Grafana Cloud

L) CI/CD Purpose: safe and rapid delivery

Design: trunk-based, ephemeral preview envs, signed artifacts

Scaling: parallelized test matrix

Failures: flaky e2e gates

Security: secret leak in pipeline

Optimization: cache deps/layers, test impact analysis

Alternatives: GitHub Actions/GitLab/Circle + ArgoCD/Flux

M) Cloud infrastructure Purpose: compute/network/storage foundation

Design: multi-AZ baseline, multi-region for top tier

Scaling: K8s autoscaling + managed DB replicas

Failures: AZ outage

Security: over-permissive IAM

Optimization: spot/mix instances + rightsizing

Alternatives: AWS/GCP/Azure hybrid

N) CDN Purpose: low-latency global delivery + DDoS shield

Design: edge cache static + API acceleration

Scaling: provider managed

Failures: stale cache invalidation bug

Security: origin bypass

Optimization: cache keys + compressed assets

Alternatives: Cloudflare, Fastly, Akamai

O) Rate limiting Purpose: fairness + abuse + cost control

Design: global + tenant + user + endpoint + token-based limits

Scaling: Redis counters + local token buckets

Failures: counter desync

Edge cases: streaming request counted incorrectly

Security: botnet distributed abuse

Optimization: adaptive limits from behavior score

Alternatives: gateway native limiters + custom risk engine

  1. AI Layer Deep Dive OpenAI API vs self-hosted models OpenAI/API providers

Pros: fastest to market, high quality, no GPU ops burden

Cons: per-token cost, less control, data residency constraints

Self-hosted

Pros: lower long-run cost at scale, custom models, data control

Cons: MLOps complexity, GPU scheduling, reliability burden

GPU requirements (self-hosted) 7B–13B models: L40S/A10/H100 (quantized configs vary)

70B+ production quality: H100/H200/B200 class, tensor/pipeline parallelism

Use vLLM/TensorRT-LLM + continuous batching

Token streaming SSE easiest for unidirectional text

Stream tokens with sequence IDs for replay/recovery

Maintain heartbeat events to detect half-open connections

Context window handling Hard budget per request: system + memory + retrieved docs + user input + response reserve

Use priority-based truncation:

system/tool instructions

latest user turns

summarized older history

retrieved chunks top-ranked only

Prompt optimization Template versioning + A/B routing

Few-shot only where measurable lift exists

Guardrails separated from style instructions

Use automated eval harness per prompt revision

Memory trimming strategy Sliding window + rolling summary memory

Keep factual user profile separately (structured memory store)

TTL for stale memory unless user pins it

RAG architecture Ingestion pipeline: parse -> chunk -> embed -> store -> metadata index

Retrieval pipeline: query rewrite -> hybrid retrieve -> rerank -> context compression

Tenant isolation via strict metadata filters + namespace separation

Embedding storage Store vectors + raw text chunk + checksum + source doc pointer

Version embeddings by model version for painless reindexing

Model scaling Dynamic routing:

cheap fast model for draft/simple tasks

premium model for complex reasoning

fallback tree across vendors/self-hosted pools

Cost optimization response length caps per tier

semantic caching

prefix/prompt caching

batch embedding jobs

off-peak indexing

model routing by difficulty score

  1. Scalability Strategy (10 β†’ 10K β†’ 1 Lakh β†’ 10 Lakh) Stage 1: 10 users (MVP) Single region, managed DB, managed Redis

One LLM provider

Basic logging + Sentry

Goal: product learning, not infra complexity

Stage 2: 10K concurrent Kubernetes, autoscaling API/orchestrator

Redis cluster + DB read replicas

Queue-based async pipelines

Basic multi-provider AI failover

Stage 3: 1 Lakh concurrent Multi-AZ hardening

Partitioned DB and vector indexes

Dedicated inference gateway + budget controls

Regional edge routing + stronger rate/risk engine

Stage 4: 10 Lakh concurrent Multi-region active-active

Global traffic manager + data locality strategy

Control-plane/data-plane separation

Advanced admission control + graceful degradation modes

Horizontal scaling essentials Keep stateless services stateless

Externalize state to DB/cache/queue

Use idempotency keys + retry-safe APIs

Kubernetes strategy Separate node pools: API, background jobs, inference

HPA + KEDA (queue depth based scaling)

Pod disruption budgets + anti-affinity

Auto-scaling rules (example) API pods: CPU > 60% or RPS per pod > threshold

Orchestrator: in-flight generations > threshold

Workers: queue lag age > N seconds

Inference: token/s backlog and TTFT SLO breach

Traffic spikes handling edge queuing + token bucket gating

brownout features (disable expensive features temporarily)

model downgrade policy for overload windows

Queue backpressure handling cap enqueue rate per tenant

DLQ for poison tasks

adaptive retry delays + circuit breakers upstream

Distributed system challenges eventual consistency surprises

clock skew and ordering bugs

duplicate events and replay storms

tracing across async boundaries

  1. Edge Cases & Failure Handling (Mitigation Plan) AI API downtime: multi-provider failover, cached fallback response patterns, queued retry.

DB crash: automated failover, read-only degraded mode, WAL backups.

Redis crash: fallback to local rate limit + strict mode, rebuild hot cache asynchronously.

Node server overload: load-shed low-priority traffic, HPA burst scale, queue deferral.

Memory leak: heap profiling, canary rollback, pod max-memory restart policy.

Token explosion: hard max output tokens + prompt budget validator.

Abuse/prompt injection: input/output classifiers, tool-call policy checks, allowlist tool schemas.

DDoS: CDN/WAF challenge, geo/risk-based throttling, upstream autoscaling.

Slow GPU inference: route to API provider fallback, dynamic batching tuning.

Network failure: retries with jitter, circuit breakers, regional failover.

Partial response failure: resumable stream with last token index.

Rate abuse: per-user/org/device fingerprint limits + behavior scoring.

  1. Security Architecture Authentication: OIDC, MFA, short JWT TTL, refresh rotation

Authorization: RBAC + ABAC, tenant scoping everywhere

Encryption: TLS 1.3 in transit, KMS-backed encryption at rest

Rate limiting: layered (edge, gateway, app, model budget)

AI abuse prevention: moderation + policy engine + audit trails

Prompt injection protection:

isolate untrusted context

content provenance labels

tool invocation guardrails

Data isolation: tenant IDs enforced at DB, vector, cache, object store

Secure logging: PII redaction and token hashing

Compliance: SOC2 controls, GDPR deletion workflows, data residency options

  1. Performance Engineering Latency reduction

co-locate orchestrator and vector DB

reduce prompt size

parallel retrieval + moderation

Caching layers

CDN static

Redis response/embedding/query cache

prompt-prefix cache for repeated system prompts

Async architecture

non-critical tasks offloaded to queues

Event-driven design

usage, billing, analytics by event stream

Streaming responses

start streaming as soon as first token arrives

Observability stack

OpenTelemetry + Prometheus + Grafana + Loki/Tempo

Performance testing

k6/Locust/Gatling for HTTP+SSE

custom token-stream benchmarks

chaos testing (Litmus/ChaosMesh)

  1. Cost Architecture Cost buckets AI inference (largest variable cost in early stages)

GPU hosting (if self-hosting)

Compute (API/orchestrator/workers)

Storage (DB + object + vector)

Network egress/CDN

Monitoring/log ingestion

Cost per user estimation (framework) CPU/API + DB IO + cache + model tokens in/out + retrieval ops + egress Track per-tenant:

avg prompts/day

avg input/output tokens

retrieval frequency

model mix %

Optimization roadmap Enforce token budgets

Introduce model routing

Cache frequent queries/prompts

Batch embeddings and offline tasks

Negotiate provider committed-use pricing

Move heavy stable workloads to self-hosted inference

  1. DevOps & Deployment Strategy Docker architecture

minimal base images, multi-stage builds, SBOM + image signing

Kubernetes setup

namespaces by env, network policies, secret manager CSI

Rolling deployments

maxUnavailable 0 for critical APIs

Blue-green

for risky infra-level migrations

Canary releases

1% -> 5% -> 25% -> 100% with SLO gates

Health checks

liveness, readiness, startup probes

Disaster recovery

cross-region backups + failover runbooks

Backup strategy

PITR for DB, snapshot vector/index metadata, tested restore drills

  1. Production Readiness Checklist SLOs defined (latency, error rate, availability)

Error budget policy and incident response process

Multi-layer rate limiting + abuse controls

Tenant isolation tests (DB/vector/cache/object store)

Secrets rotation + least-privilege IAM

End-to-end tracing across async pipelines

Load tests at 2x expected peak

Chaos tests for DB/Redis/provider failures

Runbooks for top 20 incidents

Billing metering verified vs model provider usage

Backup + restore drill passed

Canary rollback automation validated

Compliance controls mapped (audit logs, retention, deletion)

  1. Step-by-Step Learning Roadmap (for you) Phase 1 (0–6 weeks): MVP fundamentals Learn:

REST APIs, auth basics, Redis, Postgres, SSE streaming

one provider integration + conversation persistence Ignore initially:

multi-region, self-hosted LLM, complex service mesh

Phase 2 (6–12 weeks): Reliability & scale basics Learn:

Kubernetes basics, autoscaling, queues, tracing

rate limiting, retries, idempotency, circuit breaker Build:

RAG v1, usage metering, feature flags

Phase 3 (3–6 months): Production hardening Learn:

partitioning/sharding, failure testing, incident management

security controls, tenant isolation, compliance foundations Build:

multi-provider routing, cost governance, canary releases

Phase 4 (6–12 months): Enterprise scale Learn:

multi-region architecture, advanced observability, SRE practices

GPU inference ops (if moving self-hosted) Build:

active-active strategy, advanced risk engine, policy governance

Common junior pitfalls to avoid overbuilding too early (premature microservices)

ignoring idempotency and retries

no token budget controls (cost explosion)

poor traceability (can’t debug distributed failures)

weak tenant isolation assumptions

Suggested Reference Stack (2026 practical default) Frontend: Next.js + TypeScript

API: Go or Node (Fastify/Nest) + gRPC internal

Orchestration: Python/Go service

DB: Postgres + read replicas/partitioning

Vector: Qdrant/Weaviate/Pinecone

Cache: Redis Cluster

Queue: Kafka + SQS/Rabbit hybrid

Infra: Kubernetes + ArgoCD + Terraform

Observability: OpenTelemetry + Prometheus + Grafana + Loki/Tempo

Security: OIDC + OPA + Vault/KMS + WAF/CDN

If you want, next I can give you:

a concrete 3-month implementation plan (weekly milestones), and

a reference microservice repo structure with API contracts and schema designs.

Commands used βœ… pwd && rg --files -g 'AGENTS.md'

βœ… find .. -name AGENTS.md -print

About

Resources

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • TypeScript 62.3%
  • JavaScript 35.8%
  • Other 1.9%