Part of the Sanchayam series. Why a Queue A price fetch is an external API call. It can be slow, it can fail, it needs rate limiting, and it should not block a user request. The right place for it is a background worker draining a persistent queue, not an inline synchronous call. When the frontend requests holdings data and a price is missing or stale, the backend responds immediately with what it has and enqueues the asset for a fetch. The next time the user loads the page, the price is ready. There is no blocking wait. ...

Part of the Sanchayam series. Why FX Matters Sanchayam tracks assets in their native currency. An Indian equity is priced in INR. A US stock is priced in USD. Crypto may be in USD or USDT. A bank account might be in AED. The portfolio view needs to aggregate everything into one base currency (the user’s choice - INR by default). Every portfolio snapshot, every holdings page, every P&L calculation requires converting across currencies. FX rates are fetched from the same Twelve Data API used for price feeds. A naive approach - one API call per currency per request - would be both slow and expensive. ...

Part of the Sanchayam series. Invite-Only Signup Sanchayam is a personal finance tool. There is no public registration. New users are added by invitation from an existing user. The first user is created via a /setup endpoint that is only active when the database has no users. An invitation is a row in the invitations table: CREATE TABLE invitations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), token_hash VARCHAR NOT NULL UNIQUE, label VARCHAR, email VARCHAR, expires_at TIMESTAMP NOT NULL, used_at TIMESTAMP, created_by UUID NOT NULL REFERENCES users(id), created_at TIMESTAMP NOT NULL DEFAULT NOW() ); The token itself is never stored - only its SHA-256 hash. The invitation link sent by email contains the raw token. When the signup form is submitted, the backend hashes the submitted token and looks up the hash. If the row exists, is not yet used, and has not expired, signup proceeds and used_at is set. The raw token cannot be reconstructed from the hash, so a database leak does not expose valid invitation links. ...

Part of the Sanchayam series. The Problem with Per-Type Tables The obvious design for a multi-asset tracker is a table per asset type: one for stocks, one for mutual funds, one for real estate. That approach breaks down when you need cross-asset aggregation. Computing total portfolio value means querying five different tables and unioning them. Adding a new asset type means new tables, new routes, new UI components. Sanchayam uses a single assets catalog and a single holdings table. Behavior differences between asset types are encoded in schema flags, not in separate tables. ...

What Sanchayam is a self-hosted multi-asset portfolio tracker. It tracks equity (Indian and US markets), mutual funds, crypto, bank balances, and real estate under one unified schema. It computes FIFO cost basis, realized P&L, and XIRR per holding and across the entire portfolio. It handles multiple currencies with automatic FX conversion. Multiple users can share a family portfolio view. Live: sanchayam.com - hosted version, request access and use it directly Backend: github.com/sagarnayak/sanchayamBackend-public Frontend: github.com/sagarnayak/sanchayamFrontend-public Why Most portfolio trackers are either too narrow (they handle equities but not real estate), too opinionated (they force a specific cost basis method), or they require handing your financial data to a third party. Sanchayam is self-hosted, schema-driven, and designed for the full breadth of assets a typical Indian investor actually holds: listed equities, unlisted holdings, mutual fund NAVs, crypto, bank balances across currencies, and illiquid real estate. ...