Summary
Our database interaction layer is currently suffering from connection leaks and unoptimized queries. Under high load, we are occasionally spinning up new connections per request rather than utilizing a global pool, which quickly exhausts the PostgreSQL connection limits. Furthermore, endpoints like the admin dashboard are triggering full table scans on the transactions table.
This overhaul requires standardizing the pg connection pool with strict lifecycle management (e.g., graceful shutdown on SIGTERM). We also need to introduce composite indexes on frequently queried columns (like status and created_at) to optimize the SEP-31 receiver lookups and prevent race conditions during concurrent webhook deliveries.
Acceptance Criteria
Tech Stack
TypeScript (Node.js 24), pg (node-postgres), PostgreSQL 16.
Summary
Our database interaction layer is currently suffering from connection leaks and unoptimized queries. Under high load, we are occasionally spinning up new connections per request rather than utilizing a global pool, which quickly exhausts the PostgreSQL connection limits. Furthermore, endpoints like the admin dashboard are triggering full table scans on the transactions table.
This overhaul requires standardizing the
pgconnection pool with strict lifecycle management (e.g., graceful shutdown on SIGTERM). We also need to introduce composite indexes on frequently queried columns (likestatusandcreated_at) to optimize the SEP-31 receiver lookups and prevent race conditions during concurrent webhook deliveries.Acceptance Criteria
pgconnection pool with a max of 50 connections.transactionstable to eliminate sequential scans.Tech Stack
TypeScript (Node.js 24),
pg(node-postgres), PostgreSQL 16.