Production fintech patterns
An engineer outlined a production fintech stack that relies on a Kafka transactional outbox, optimistic locking, multi-currency FX handling and double-entry ledgers to keep cross-service writes consistent and durable. Those concrete patterns aim to address common failure modes in high-throughput lending and payments systems. (x.com) (x.com)
A payment system is a running record of who owes what, who got paid, and whether every dollar has a matching counter-entry. Stripe said in February 2024 that it built Ledger as an immutable, auditable system of record for money movement, while an engineer’s recent post laid out the same core production patterns many fintech teams use to keep those records consistent across services. (stripe.dev) (x.com) The first problem is the “dual write”: one service updates its database, then tries to publish an event to Apache Kafka so other services can react. Confluent and Amazon Web Services both describe the failure mode plainly: if one write succeeds and the other fails, downstream systems can miss a state change or process a change that never committed. (developer.confluent.io) (docs.aws.amazon.com) The transactional outbox pattern fixes that by writing business data and an “outbox” message into the same database transaction, then letting a separate process deliver that message to Kafka later. Confluent compares the outbox to a mailbox, and Amazon Web Services says consumers should still be idempotent because duplicate messages can happen. (developer.confluent.io) (docs.aws.amazon.com) The second problem is two requests trying to change the same balance at once, like two repayments hitting one loan account within milliseconds. Martin Fowler’s Optimistic Offline Lock pattern lets both requests proceed until commit time, then rejects the one built on stale data instead of holding a long database lock the whole time. (martinfowler.com) That tradeoff fits payments and lending systems that need high concurrency without turning every hot account into a traffic jam. Fowler’s description is explicit: optimistic locking assumes conflicts are relatively rare, validates before commit, and avoids the throughput limits that come with pessimistic locking. (martinfowler.com) The third layer is the ledger itself: every movement of money gets two entries so the books stay balanced. Accounting references define double-entry bookkeeping as a system in which each transaction affects at least two accounts, and Stripe said its internal ledger standardizes money movement so teams and auditors can verify what happened. (accountingcoach.com) (stripe.dev) That matters most when a platform handles more than one currency. International Accounting Standard 21 says companies must determine which exchange rate to use and how to report the effects of exchange-rate changes, which is why production fintech systems usually store both the original currency amount and the converted reporting amount instead of treating foreign exchange as an afterthought. (ifrs.org) Stripe’s scale shows why engineers obsess over these controls. The company said it processed 300 million transactions worth $18.6 billion from Black Friday through Cyber Monday in 2023, supports more than 135 currencies and payment methods in 185 countries, and sees five billion ledger events a day. (stripe.dev) The engineer’s thread did not introduce a new standard or product release; it distilled a playbook already reflected in vendor guidance and large payments infrastructure. In practice, the stack is simple to describe and hard to implement: commit state and events together, detect stale writes before they land, and never move money without balanced ledger entries. (x.com) (developer.confluent.io) (martinfowler.com)
