Fintech Platform
Consider a payments platform: money moves, regulators audit, and a lost or double-processed transaction is a real-world loss. The requirements are strong consistency, a complete audit trail, encryption that satisfies compliance, and resilience to a regional outage with a measured, small data-loss tolerance.
This case inverts the serverless one. Where SaaS optimized for cost and scale-to-zero, fintech optimizes for correctness, auditability, and control — and pays for it. The architecture leans on the strongly consistent and durable end of every choice: a relational core, exactly-once messaging, customer-managed encryption, and a tested multi-region recovery plan.
Consistency and Data
The transactional core runs on Azure SQL Database (Business Critical, zone-redundant) for strong consistency, low-latency local replicas, and fast failover — not an eventually consistent store, because a payment ledger cannot tolerate stale reads. Exactly-once-style processing of transaction commands runs on Service Bus with sessions and transactions, so a transfer is neither lost nor applied twice.
Auditability
Every consequential action is logged immutably. Activity logs, application audit events, and security signals flow into Log Analytics and Microsoft Sentinel, with immutable storage and data-retention locks so records cannot be altered or deleted before their retention expires. Regulators ask who did what and when; the architecture answers from an append-only, tamper-evident record, not reconstructed logs.
Encryption and Secrets
Data is encrypted at rest with customer-managed keys in Key Vault (or Managed HSM for the strictest key-sovereignty), and in transit everywhere. Application secrets are fetched at runtime via managed identity. Controlling the key lifecycle is a compliance requirement here, not an option, and the HSM guarantee that keys cannot be exported is part of the audit story.
Resilience and Compliance
A second region provides disaster recovery sized to a measured RPO of seconds, achieved with the data tier's low-lag asynchronous replication — Azure SQL active geo-replication and failover groups are asynchronous, so cross-region RPO is seconds, not zero — plus a tested failover that is a rehearsed procedure, not an aspiration. Network controls (private endpoints, WAF, DDoS), least-privilege RBAC with just-in-time admin, and Defender for Cloud's compliance dashboards (PCI DSS) round out the posture.
Strong consistency (Azure SQL Business Critical) — Reads reflect the latest committed write; correct for a payment ledger. The right choice for the transactional core.
Eventual consistency (a distributed NoSQL store) — Higher availability and scale, but stale reads — unacceptable for money movement. Fine for non-ledger, read-heavy views only.
- Using an eventually consistent store for the transaction ledger, where a stale read can double-spend or lose money.
- Relying on platform-managed keys where compliance requires customer-managed keys or an HSM and control of the key lifecycle.
- Treating logs as mutable operational data instead of an immutable, tamper-evident audit record.
- Processing transaction commands without sessions and transactions, risking lost or duplicated payments.
- Claiming a small RPO without synchronous/low-lag replication and a tested failover to back it up.
- Designing for compliance once and never measuring posture drift with Defender for Cloud.
- Run the ledger on a strongly consistent, zone-redundant relational core (Azure SQL Business Critical).
- Process transaction commands on Service Bus with sessions and transactions for exactly-once handling.
- Log consequential actions immutably into Log Analytics and Sentinel for a tamper-evident audit trail.
- Encrypt with customer-managed keys (or Managed HSM) and fetch secrets via managed identity.
- Size DR to a measured RPO with low-lag asynchronous geo-replication (RPO in seconds, not zero) and rehearse the regional failover.
- Track PCI and other compliance continuously in Defender for Cloud, with least-privilege and just-in-time admin.
Knowledge Check
Why use a strongly consistent relational store for a payment ledger?
- A stale read on an eventually consistent store can double-spend or lose money; the ledger must reflect the latest committed write
- Relational stores are always cheaper to run than a comparable NoSQL store, and that lower running cost is the deciding factor here
- Eventual consistency is simply unavailable anywhere on Azure
- A NoSQL store cannot hold monetary or decimal values at all
What makes the audit trail trustworthy to a regulator?
- Consequential actions are logged immutably (tamper-evident), not reconstructed from mutable logs
- Logs are deleted on a frequent rolling schedule to keep long-term storage cost as low as possible
- Only the successful transactions are recorded in the trail
- Logs are kept inside the application's own database
What backs up a claimed RPO of seconds?
- Synchronous or low-lag data replication plus a tested regional failover
- Daily backups copied across to a second paired region on a nightly schedule
- Zone redundancy contained within a single region only
- A larger VM size provisioned for the ledger database
You got correct