Savyour Case Study — High-Throughput Fintech SaaS Ledger

The problem

Affiliate webhooks are noisy, duplicated, and financially dangerous.

Savyour operates at the intersection of hundreds of affiliate networks and consumer wallets. When a major shopping festival launched, merchant partners hammered the backend with hundreds of thousands of status updates, purchase confirmations, and order cancellations.

A single duplicate webhook processing bug would credit real money to a user's wallet twice. Without immutable double-entry bookkeeping, auditing where money entered and exited the system required manual database forensic queries.

The challenge was to engineer a high-concurrency ingestion barrier that validates signatures, guarantees idempotency, maintains absolute ledger consistency, and scales reads seamlessly.

Architecture decisions

Designing for zero financial drift and high-throughput ingestion.

Every architectural boundary prioritized mathematical auditability, cryptographic payload verification, and system resilience under volatile third-party traffic surges.

Idempotent Webhook Processing via HMAC & Redis Keys

Problem

100+ affiliate networks and merchant partners dispatch webhook notifications with unpredictable retry behaviors, out-of-order deliveries, and duplicate payloads that threatened wallet double-crediting.

Decision

Engineered an ingestion barrier verifying HMAC-SHA256 partner signatures and enforcing deterministic idempotency keys via Redis atomic operations (SETNX with 72-hour TTL) before entering async task queues.

Tradeoff accepted

Added ~15ms of ingestion verification latency, but mathematically eliminated duplicate transaction credits across millions of webhook events.

Immutable Double-Entry Ledger with Serializable PostgreSQL

Problem

Concurrent transaction events (crediting cashback while users initiated bank withdrawals) risked balance drift, race condition exploits, and non-reconcilable financial discrepancies.

Decision

Implemented a strict double-entry bookkeeping ledger where user balances are computed from immutable credit/debit transaction lines under PostgreSQL Serializable isolation levels.

Tradeoff accepted

Requires rigorous transaction isolation and advisory locks on hot accounts, but guarantees 100% financial audit integrity.

Two-Tier Hierarchical Redis Invalidation Architecture

Problem

Shopping festival surges caused millions of concurrent database queries against brand commission tables, partnership tiers, and user balance caches, threatening database saturation.

Decision

Designed a hierarchical Redis caching architecture with namespace-level invalidation triggered via admin partner updates and probabilistic early expiration (XFetch) to prevent cache stampedes.

Tradeoff accepted

Cache eviction patterns require exact key hygiene across microservices, but achieved a sustained 99.4% cache hit ratio during peak campaigns.

Decoupled Asynchronous Payout Outbox Engine

Problem

Third-party banking APIs and 1-Link payout gateways frequently timed out or rate-limited requests during high-volume withdrawal windows, blocking client threads.

Decision

Implemented the Transactional Outbox pattern, queueing payout jobs in Celery/RabbitMQ with exponential backoff, jittered retries, and automated operator dead-letter escalation.

Tradeoff accepted

Payouts execute asynchronously with a 1-2 minute verification window rather than synchronous execution, but unhandled gateway failures dropped to zero.

System architecture

How the financial pipeline flows.

Financial Ingestion & Ledger Security Boundary

100+ Partner WebhooksAffiliate networks & merchants

HMAC & Idempotency GateSHA-256 validation & Redis SETNX

Async Task Queue (Celery)Decoupled event calculation & commission splits

Two-Tier Redis CacheCached brand tiers & balance reads

Payout Outbox EngineBank & 1-Link gateway dispatch queue

Double-Entry Ledger StorePostgreSQL Serializable ACID records

Redis Sentinel

Idempotency & cache cluster

PostgreSQL RDS

ACID double-entry ledger

RabbitMQ / Celery

Async transaction queues

Bank & 1-Link APIs

Disbursement endpoints

Double-entry consistency guaranteed. Balance queries never read arbitrary mutable columns; they verify the sum of signed credit/debit entries across auditable ledger accounts.

Failure modes & defenses

How financial edge cases and ingestion failures are neutralized.

Financial ledgers cannot rely on optimistic assumptions. These are the worst-case failure scenarios pressure-tested during implementation and the concrete defenses engineered into the backend.

Failure Mode 01

Duplicate Affiliate Conversion Webhooks

Financial Risk

Network retries from merchant affiliate networks crediting the consumer's wallet multiple times for a single order.

Architectural Defense

HMAC request signature verification coupled with atomic Redis idempotent key caches (7-day TTL). Duplicate requests resolve to cached 200 OK without reaching the database.

Failure Mode 02

Database Lock Contention on Balances

Financial Risk

Multiple cashback events trying to mutate the same user's balance row concurrently, leading to transaction rollbacks.

Architectural Defense

Immutable append-only ledger architecture. New transactions write new credit/debit journal rows with zero row locks on user profiles, with balances projected asynchronously.

Failure Mode 03

Redis Eviction & Cache Stampede

Financial Risk

Sudden cache invalidation on popular brand commission rates triggering hundreds of simultaneous PostgreSQL queries.

Architectural Defense

Hierarchical cache warming with probabilistic early expiration (XFetch) and distributed mutex locking on cache misses to ensure only one worker re-queries PostgreSQL.

Failure Mode 04

Order Return Fraud & Chargebacks

Financial Risk

Consumers collecting cashback and immediately cancelling the purchase on the merchant's store.

Architectural Defense

Two-phase settlement state machine (Pending -> Verified -> Cleared). Cashback remains locked in escrow until the merchant's return dispute window expires.

Outcomes

Hard metrics from real consumer scale.

Eliminated duplicate payout exploits while maintaining responsive balance reads during peak nationwide retail promotions.

100+

Integrated brand partners

Supported across Daraz, Foodpanda, local retailers, and international affiliate networks without ingestion failures.

99.4%

Cache hit ratio

Sustained cache hit rate on high-velocity brand commission queries during national shopping campaigns.

<50ms

P95 wallet query latency

Cached balance retrieval under high concurrent mobile consumer traffic.

100%

ACID ledger reconciliation

Zero financial balance discrepancies across millions of double-entry ledger line items.

Savyour High-Throughput Fintech SaaS Ledger

Affiliate webhooks are noisy, duplicated, and financially dangerous.

The financial rules that governed every database transaction.

<50ms P95 Balance Lookups

Double-Entry Balance Accounting

Burst Ingestion Capacity

Designing for zero financial drift and high-throughput ingestion.

Idempotent Webhook Processing via HMAC & Redis Keys

Immutable Double-Entry Ledger with Serializable PostgreSQL

Two-Tier Hierarchical Redis Invalidation Architecture

Decoupled Asynchronous Payout Outbox Engine

How the financial pipeline flows.

How financial edge cases and ingestion failures are neutralized.

Duplicate Affiliate Conversion Webhooks

Database Lock Contention on Balances

Redis Eviction & Cache Stampede

Order Return Fraud & Chargebacks

Fourteen weeks to enterprise financial stability.

Hard metrics from real consumer scale.

Integrated brand partners

Cache hit ratio

P95 wallet query latency

ACID ledger reconciliation

Building high-concurrency transactional systems?