Developer Documentation

Database Scaling

Database Scaling

SikaaHub is ledger-first. Balances are cached state; ledger and transactions are the audit source of truth.

Indexing

High-volume tables use public IDs, status indexes, created-at indexes, and composite indexes for customer, merchant, status, and transaction type filters.

Pagination

Transaction history should use cursor pagination based on created_at plus id or ULID-style public IDs. Avoid large OFFSET scans.

Partitioning Plan

When volume grows, partition these tables by month:

• transactions
• ledger_entries
• request_logs
• provider_transactions
• webhook_events

Partitioning should be introduced only after testing backup, restore, and query plans.

Read Scaling

Use a read replica for analytics, admin reporting, reconciliation review, and exports. Financial writes must stay on the primary database.

Backup Strategy

Use daily encrypted backups, binlog retention, restore drills, and separate secure backup of .env. Ledger and transaction backup integrity is critical.

Queue Scaling

Move from the database-backed jobs table to a dedicated queue when webhook volume or notification throughput outgrows the pilot phase.