Real fintech stack example

Moving money in software is not a balance counter; it is a record of every move in and out, with both sides written down. A developer’s July 2025 post laid out that pattern in a live fintech stack, from customer portals to a ledger and event pipeline. (x.com) The post describes separate portals for different roles, including customers and operations staff, instead of one back office doing everything. It also shows one-time passcode transfer approval, foreign-exchange handling for multiple currencies, and a ledger at the center of every transaction flow. (x.com) At the core is double-entry bookkeeping, the accounting rule that every transfer creates matching debit and credit records. Reference architectures for modern ledgers use that model so value is moved between accounts rather than created by overwriting a single balance field. (aandz.tech, sagard.com) That design is aimed at common failure modes in payment systems: two requests spending the same funds, dashboards disagreeing with the ledger, and support teams unable to explain a balance. Aandz’s reference architecture lists race conditions, data drift, and audit gaps as the problems that appear when teams rely on a simple “credits remaining” column. (aandz.tech) The post also includes a Kafka outbox, a pattern for avoiding the “database updated, message never sent” problem in distributed systems. Confluent and Microservices.io describe the approach as writing business data and an outbox event in the same database transaction, then publishing that event to Apache Kafka from a separate relay. (developer.confluent.io, microservices.io) That matters when a transfer triggers other work, like updating balances, notifying users, or feeding reporting systems. Kafka’s delivery model can still retry messages, so teams pair the outbox with idempotent processing, which means the same request can be replayed without posting the transfer twice. (docs.confluent.io, aandz.tech) The architecture also uses optimistic locking, a way to let two requests try to update the same record and reject the loser if the record changed first. PostgreSQL documents concurrency control as the system for preserving data integrity when sessions access the same data at the same time, and common optimistic schemes do that with a version or token check. (postgresql.org, npgsql.org) Multi-currency support adds another layer because the system has to track both the original funds and the foreign-exchange conversion without losing the audit trail. Ledger vendors and case studies now market this as table stakes for wallets, payments, cards, and cross-border products that need reconciliation across processors, banks, and internal accounts. (blnkfinance.com, byteandrise.com) The thread landed as more developers publish “reference architectures” for financial cores instead of toy wallet demos. Those blueprints now center on immutable ledgers, event streams, observability, and replayable history because transaction-heavy systems have to explain every cent after the fact, not just process it in real time. (aandz.tech, sagard.com) The appeal of the post is its concreteness: role-separated apps, approval checks, a ledger, and a message trail tied together in one diagram. For engineers building wallets or payment rails, it reads less like a theory lesson than a checklist of what has to work before real money moves. (x.com, aandz.tech)