In a financial system, the database is the source of truth. If a balance is wrong there, it is wrong everywhere, and no amount of clean application code can fix it afterwards. This module covers how to store money-related data so that every balance can be explained, audited, and trusted.
You'll start with relational databases and PostgreSQL, the usual choice for financial data. Then you'll look at ACID transactions, which make sure a transfer either happens completely or not at all, even when several requests arrive at once. Finally, you'll learn double-entry bookkeeping, the accounting method behind almost every serious ledger: every movement of money is recorded as a debit in one account and a credit in another, so the books always balance.
Along the way you'll see why ledgers are append-only, why corrections are new entries rather than edits, and why idempotency keys are used to stop a retried request from posting the same payment twice. Once you've finished this module, move on to Payments Integration.
A quick introduction to PostgreSQL: tables and SQL, ACID-compliant transactions, concurrency through MVCC, primary and foreign keys, and joins between tables.
What a database transaction is and what atomicity, consistency, isolation, and durability each guarantee, the properties that keep balances correct when things go wrong.
How transactions are recorded in general ledger accounts, and how to remember which accounts increase with a debit and which with a credit.