datamint

A self-serve reporting layer over MongoDB. Non-technical staff generate the reports they need; engineers stop being a human report-API.

🔗 Live app · 📐 System Design / HLD · 👤 Built end-to-end by Mahesh Konar

Note: datamint is an in-development SaaS product. The source code is private. This repository shares the system design behind it - the problem, the architecture, and the reasoning behind every major decision.

---

The problem

Every MongoDB-backed product ends up with the same Slack message: "hey, can you pull a quick report of X?" - and an engineer writes a one-off aggregation, exports a CSV, and does it again next week. datamint turns that into self-serve: an ops or business user connects a read-only MongoDB credential, picks collections and fields, applies filters, and gets a repeatable report - no engineer in the loop.

What it does

• Connect any MongoDB deployment with a read-only connection string - stored encrypted, never readable again, even by us.
• Build reports over collections with field selection, filtering, and pagination - no aggregation-pipeline knowledge required.
• Multi-tenant by design - organizations, roles, and per-org isolation from day one.

Architecture at a glance

Next.js (app) → Express/TypeScript API → PostgreSQL (app data: orgs, users, roles, report configs)
                                       ↘ customer's MongoDB (read-only, per-request, credentials decrypted just-in-time)

Key decisions (full reasoning in the HLD):

• Two databases, on purpose. PostgreSQL holds datamint's own relational data - orgs, users, roles, saved report configs - where transactions and constraints matter. The customer's MongoDB is only ever touched read-only, per request. Mixing the two would couple our uptime to theirs and vice versa.
• Credentials encrypted at rest with AES-256-GCM. Authenticated encryption: a stolen database yields ciphertext that cannot be read or silently tampered with. The key lives only in the runtime environment. The exact pattern is extracted into a runnable, tested repo: aes-256-gcm.
• Org → role access control. Multi-tenant RBAC so an org admin manages members and viewers run reports - deny by default.

Read the design

• System Design / HLD → - the problem, architecture, the two-database design and why, AES-256-GCM secret encryption, request flow, and scaling plan.

Related demonstrator repos

The patterns described in the HLD are implemented as standalone, runnable demos:

• aes-256-gcm - the authenticated-encryption pattern used to store connection strings.

Stack

Next.js · Express · TypeScript · PostgreSQL · MongoDB (read-only client) · AES-256-GCM · Vercel

---

Designed and built by Mahesh Konar - LinkedIn · konartech@gmail.com