Lending Marketplace CRM
The internal system of record for a home-loan marketplace — every lead, partner, document and loan stage from first enquiry through disbursal, running as a set of Node.js and Python services.
Client
Fintech (India)
Service
Platform Engineering
Date
June 1, 2026
Challenge
A loan file passes through sales, credit, operations and a lender before money moves, and each hand-off has its own rules, documents and SLAs. Off-the-shelf CRMs model a sales pipeline, not a regulated lending workflow, so the process lived in spreadsheets and manual follow-ups that nobody could audit.
Solution
Domain-split services behind a single gateway, with a relational store as the source of truth for lead and loan state, a document store for payload-heavy records, a message broker for cross-service workflow, and a cache for the lookups every screen needs.
The problem
A home loan is not a transaction, it is a two-month process. An enquiry becomes a qualified lead, a lead becomes a case with documents attached, the case goes to one or more lenders, each lender asks its own questions, credit comes back with conditions, and only then does money move — sometimes in one payment, more often in several.
Every one of those steps has an owner, a deadline and a rule about what is allowed to happen next. A generic CRM models none of it. Before this system existed, the state of a case lived in whichever spreadsheet its owner maintained, which meant nobody could answer “where is this file stuck” without asking three people.
What was built
A set of services split by domain rather than by layer — lead capture and qualification, case and document management, lender submission, and disbursal — each owning its own data and talking to the others through a broker rather than reaching into shared tables. A gateway sits in front, so the many internal frontends see one API surface and one authentication story.
The relational database holds lead and loan state, because that state is what everything reconciles against and it needs constraints. A document store holds the payload-heavy records: uploaded files, third-party API responses, event history. A cache absorbs the read pressure from dashboards that poll constantly.
The part that mattered
Stage transitions are the whole product. Each one is validated server-side against the rules for that product and that lender, emitted as an event, and recorded so the history of a case can be replayed. That is what made the system trustworthy enough to run operations on: not the screens, but the fact that a case cannot silently be in a state it never legally reached.
Stack
Node.js and Python services, MySQL, MongoDB, RabbitMQ, Redis, AWS.