KhataGO

System Architecture

KhataGO is a WhatsApp-first bookkeeping platform for Indian MSMEs. The backend is a reconciliation pipeline: Meta webhooks arrive with at-least-once delivery, and idempotency is enforced in Postgres rather than a cache — a unique constraint on the WhatsApp message id rejects duplicate deliveries, and a conditional UPDATE (PENDING→PROCESSING) atomically claims each message so concurrent redeliveries produce exactly one Gemini run instead of a double ledger write. The webhook persists the message and acknowledges Meta within the request; a containerized polling worker drains the queue — the same Postgres table, claimed through the same atomic UPDATE, retried with exponential backoff and jitter, and dead-lettered after three attempts with an audited admin replay. Gemini 2.0 Flash with function-calling parses both text ('Sold 500 to Ram') and receipt images (OCR → structured JSON with merchant/amount/date/line items) into 10 tool calls — create_transaction, create_receivable, record_payment_received, get_party_ledger, send_payment_reminder, and others — each mapped to a Prisma write. Results flow back to the user over WhatsApp; a CA portal exports Tally-ready XML vouchers for month-end close. In the repository (merged 2026-09-05, not yet deployed), the tool-calling loop runs as an explicit, resumable state machine: the model's plan for each turn is persisted before any tool runs, and a write tool commits in the same transaction as its step, so a crash resumes from the last durable turn and at-most-once execution is a property of the database rather than of control flow. Bring-your-own Gemini keys get per-key cooldown isolation, so one user's 429 does not park a model for everyone. Each run is traced as one document (Postgres JSONB by default, a MongoDB adapter opt-in); 21 deterministic evals run in CI through promptproof under both the default loop and a LangGraph.js rendering behind a flag; retention crons bound traces and runs.