Decoupling Payments and Wallets: From Order Domain to a Unified Accounting Center

When an order service both changes order status and deducts balances, writes flow records, handles payment callbacks, and performs refund compensation, the system appears "functionally consolidated" but actually forces transaction, fund, and channel uncertainties into a single domain model. Under traffic spikes and long call chains, the first thing to break is usually the domain boundaries, not the code.

Problem background – why many systems break their wallet

Typical early architecture:

Order service creates an order.

Order service checks if user balance is sufficient.

Order service directly deducts user_account.balance.

Order service writes an account_flow record.

Order service calls the payment channel.

After the asynchronous channel callback, the order service still updates order status and compensates the flow.

This scheme is convenient at the start because there is only one service, one database, a few tables, low development cost, fast integration, and transactions seem easy to control. As business complexity grows, the following problems almost inevitably appear:

Order tables simultaneously hold order status and fund status, causing severe hotspot row‑lock conflicts.

Payment callbacks arrive late or duplicate, leading to balance double‑processing.

Refund and payment execute concurrently, causing state‑machine cross‑pollution.

Order service accumulates more and more fund rules; any change ripples through the whole system.

When multiple business lines need wallet access, each service re‑implements the "deduct balance + write flow + compensate" wheel.

Clarifying domain boundaries

Order domain – maintains order lifecycle ( Order, OrderItem, OrderStatus). Should NOT modify account balance or understand channel callbacks.

Payment domain – organizes payment requests and channel interaction ( PaymentOrder, PaymentAttempt, ChannelTrade). Should NOT hold total ledger or maintain account balance.

Wallet domain – provides user fund account capability ( WalletAccount, SubAccount). Should NOT depend on order state machine.

Accounting domain – records fund facts and generates accounting vouchers ( LedgerEntry, Journal, BalanceSnapshot). Should NOT care how a business button triggers the flow.

Evolution goal – from "business balance change" to "event‑driven unified accounting"

Order domain only maintains order status, never directly manipulates account balance.

Payment domain only handles payment orders, channel requests, callback verification, and payment‑status unification.

Wallet/accounting center uniformly processes accounts, balances, flows, vouchers, reconciliation, and compensation.

Services collaborate via domain events instead of sharing database tables.

All fund changes converge into standardized accounting requests rather than scattered SQL.

What the unified accounting center actually abstracts

Fund facts – immutable flow records.

Fund state – multiple balance views (available, frozen, pending, booked).

Fund constraints – invariants that must hold.

Fund facts – flow is the source data, balance is a snapshot

Key principles:

Flows can only be inserted; they cannot be arbitrarily updated or deleted.

Balance tables are materialized snapshots for query efficiency.

In disputes, the flow and voucher are authoritative, not a cached balance.

A mature accounting system has at least two layers of data:

Accounting entry table ledger_entry – the finest‑grain fact record.

Balance snapshot table account_balance – the latest values for quick queries and risk checks.

Fund state – multiple balance containers

available_amount

– usable balance. frozen_amount – frozen balance. pending_amount – amount in processing. booked_amount – ledger (book) balance.

Fund constraints – core invariants

1. Single‑account fund invariant opening_balance + delta = closing_balance If balances are split by type, each must satisfy:

opening_available + delta_available = closing_available
opening_frozen    + delta_frozen    = closing_frozen
opening_booked    + delta_booked    = closing_booked

2. Double‑entry bookkeeping conservation sum(debit_entries.amount) = sum(credit_entries.amount) 3. Business idempotency invariant – every accounting action needs a unique business key such as request_id, payment_id, refund_id, ledger_txn_no. Idempotency is a survival condition for a fund system.

Overall architecture – service boundaries

order-service

– order state machine, timeout closure, fulfillment linkage. payment-service – payment orders, attempts, channel callbacks, status unification. wallet-service – account query, balance freeze/unfreeze, user‑wallet API. accounting-service – unified posting, balance snapshot, flow, voucher, reconciliation, compensation.

Why payment success should not directly modify the order

Payment domain confirms payment success.

Payment domain publishes PaymentSucceeded.

Accounting center completes posting and writes flow.

Accounting center publishes LedgerPosted.

Order domain consumes LedgerPosted and finally updates order to "paid".

Order‑paid determination is based on internal fund entry completion, not merely on channel callback.

Core business scenario – mixed‑payment order flow

Example:

Order amount: 299.00 CNY

Wallet deduction: 100.00 CNY

WeChat payment: 199.00 CNY

If merchant out of stock after payment, a full refund is required.

Key requirements:

Wallet deduction must be frozen first and finally deducted.

WeChat payment result is determined by asynchronous callback.

Refund returns wallet part to wallet and channel part to original channel.

User must never see a "order not paid but money taken" dirty state.

Data model design – table definitions

Account balance table

CREATE TABLE account_balance (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  account_no VARCHAR(64) NOT NULL,
  account_type VARCHAR(32) NOT NULL,
  subject_code VARCHAR(32) NOT NULL,
  currency CHAR(3) NOT NULL DEFAULT 'CNY',
  available_amount DECIMAL(18,2) NOT NULL DEFAULT 0.00,
  frozen_amount DECIMAL(18,2) NOT NULL DEFAULT 0.00,
  booked_amount DECIMAL(18,2) NOT NULL DEFAULT 0.00,
  version BIGINT NOT NULL DEFAULT 0,
  created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  UNIQUE KEY uk_account_no_subject (account_no, subject_code, currency),
  KEY idx_updated_at (updated_at)
) ENGINE=InnoDB;

Ledger transaction header table

CREATE TABLE ledger_transaction (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  ledger_txn_no VARCHAR(64) NOT NULL,
  request_id VARCHAR(64) NOT NULL,
  biz_type VARCHAR(32) NOT NULL,
  biz_order_no VARCHAR(64) NOT NULL,
  payment_id VARCHAR(64) DEFAULT NULL,
  status VARCHAR(16) NOT NULL,
  amount DECIMAL(18,2) NOT NULL,
  currency CHAR(3) NOT NULL DEFAULT 'CNY',
  idempotency_key VARCHAR(128) NOT NULL,
  ext_json JSON DEFAULT NULL,
  created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  UNIQUE KEY uk_ledger_txn_no (ledger_txn_no),
  UNIQUE KEY uk_idempotency_key (idempotency_key),
  KEY idx_biz_order_no (biz_order_no),
  KEY idx_payment_id (payment_id)
) ENGINE=InnoDB;

Ledger entry table (fund facts)

CREATE TABLE ledger_entry (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  ledger_txn_no VARCHAR(64) NOT NULL,
  entry_no VARCHAR(64) NOT NULL,
  account_no VARCHAR(64) NOT NULL,
  subject_code VARCHAR(32) NOT NULL,
  direction VARCHAR(8) NOT NULL,
  amount DECIMAL(18,2) NOT NULL,
  balance_type VARCHAR(16) NOT NULL,
  biz_order_no VARCHAR(64) NOT NULL,
  request_id VARCHAR(64) NOT NULL,
  created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  UNIQUE KEY uk_entry_no (entry_no),
  KEY idx_ledger_txn_no (ledger_txn_no),
  KEY idx_account_no_created (account_no, created_at),
  KEY idx_request_id (request_id)
) ENGINE=InnoDB;

Idempotency record table

CREATE TABLE idempotency_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  idempotency_key VARCHAR(128) NOT NULL,
  processor VARCHAR(64) NOT NULL,
  status VARCHAR(16) NOT NULL,
  response_json JSON DEFAULT NULL,
  created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  UNIQUE KEY uk_idempotency_key_processor (idempotency_key, processor)
) ENGINE=InnoDB;

Outbox event table (local‑transaction + MQ pattern)

CREATE TABLE outbox_event (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  event_id VARCHAR(64) NOT NULL,
  aggregate_type VARCHAR(32) NOT NULL,
  aggregate_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(64) NOT NULL,
  payload_json JSON NOT NULL,
  status VARCHAR(16) NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_at DATETIME(3) NOT NULL,
  created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  UNIQUE KEY uk_event_id (event_id),
  KEY idx_status_next_retry (status, next_retry_at)
) ENGINE=InnoDB;

Core process design – normal, duplicate, and compensation flows

Normal payment flow – payment service publishes PaymentSucceeded, accounting service posts ledger, writes outbox event, then order service consumes LedgerPosted to mark order paid.

Duplicate channel callback flow – payment service must be idempotent; accounting service must also be idempotent for the same PaymentSucceeded event; order service must be idempotent for LedgerPosted. No component assumes a single upstream call.

Ledger posted but order not updated – fund facts cannot be rolled back; subsequent retries or compensation bring the order status up to date.

Refund flow – refund creates a new reverse accounting transaction; original flow is never deleted.

Consistency solution comparison

Single‑DB local transaction – simple, strong consistency; only fits early monoliths.

Local message table + MQ – easy to adopt, high throughput, eventual consistency; requires full idempotency and compensation.

Transactional message – tighter bind between send and local transaction; depends on specific MQ (e.g., RocketMQ).

TCC – strong control for freeze‑confirm‑cancel scenarios; intrusive, complex, high cost; suitable for pre‑authorization, guarantee, installment pre‑auth.

Saga – fits long‑running orchestrations; compensation design is complex; used when many strong‑business domains are involved.

The recommended mainline solution is:

Local transaction + Outbox + Kafka + Idempotent consumer + Scheduled compensation + Reconciliation check

Reasons: higher throughput, clearer service boundaries, richer observability and recovery, and natural fit for asynchronous payment callbacks.

Production‑grade implementation – core code

Unified posting command object

public record PostLedgerCommand(
        String requestId,
        String idempotencyKey,
        String bizType,
        String bizOrderNo,
        String paymentId,
        BigDecimal amount,
        Currency currency,
        List<LedgerLineCommand> lines,
        Map<String, Object> ext) {
    public void validate() {
        Assert.hasText(requestId, "requestId must not be blank");
        Assert.hasText(idempotencyKey, "idempotencyKey must not be blank");
        Assert.hasText(bizType, "bizType must not be blank");
        Assert.hasText(bizOrderNo, "bizOrderNo must not be blank");
        Assert.notNull(amount, "amount must not be null");
        Assert.isTrue(amount.compareTo(BigDecimal.ZERO) > 0, "amount must be positive");
        Assert.notNull(currency, "currency must not be null");
        Assert.notEmpty(lines, "lines must not be empty");
        BigDecimal debit = lines.stream()
                .filter(l -> l.direction() == EntryDirection.DEBIT)
                .map(LedgerLineCommand::amount)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
        BigDecimal credit = lines.stream()
                .filter(l -> l.direction() == EntryDirection.CREDIT)
                .map(LedgerLineCommand::amount)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
        Assert.isTrue(debit.compareTo(credit) == 0, "debit must equal credit");
    }
}

Ledger posting service

@Service
public class LedgerPostingService {
    private static final Logger log = LoggerFactory.getLogger(LedgerPostingService.class);
    private final IdempotencyRepository idempotencyRepository;
    private final LedgerTransactionRepository ledgerTransactionRepository;
    private final LedgerEntryRepository ledgerEntryRepository;
    private final AccountBalanceRepository accountBalanceRepository;
    private final OutboxEventRepository outboxEventRepository;

    public LedgerPostingService(IdempotencyRepository idempotencyRepository,
                               LedgerTransactionRepository ledgerTransactionRepository,
                               LedgerEntryRepository ledgerEntryRepository,
                               AccountBalanceRepository accountBalanceRepository,
                               OutboxEventRepository outboxEventRepository) {
        this.idempotencyRepository = idempotencyRepository;
        this.ledgerTransactionRepository = ledgerTransactionRepository;
        this.ledgerEntryRepository = ledgerEntryRepository;
        this.accountBalanceRepository = accountBalanceRepository;
        this.outboxEventRepository = outboxEventRepository;
    }

    @Transactional(rollbackFor = Exception.class)
    public LedgerPostingResult post(PostLedgerCommand command) {
        command.validate();
        IdempotencyRecord existing = idempotencyRepository.find(
                command.idempotencyKey(), "LedgerPostingService");
        if (existing != null && "SUCCESS".equals(existing.getStatus())) {
            return Jsons.fromJson(existing.getResponseJson(), LedgerPostingResult.class);
        }
        String ledgerTxnNo = LedgerTxnNos.nextTxnNo();
        LedgerTransaction txn = LedgerTransaction.init(
                ledgerTxnNo, command.requestId(), command.bizType(),
                command.bizOrderNo(), command.paymentId(), command.amount(),
                command.currency(), command.idempotencyKey(), command.ext());
        ledgerTransactionRepository.insert(txn);
        List<String> lockedAccounts = command.lines().stream()
                .map(LedgerLineCommand::accountNo)
                .distinct()
                .sorted()
                .toList();
        Map<String, AccountBalance> balances = accountBalanceRepository
                .selectForUpdate(lockedAccounts)
                .stream()
                .collect(Collectors.toMap(AccountBalance::getAccountNo, Function.identity()));
        for (LedgerLineCommand line : command.lines()) {
            AccountBalance balance = balances.get(line.accountNo());
            if (balance == null) {
                throw new IllegalStateException("account not found: " + line.accountNo());
            }
            applyLine(balance, line);
            accountBalanceRepository.update(balance);
            ledgerEntryRepository.insert(LedgerEntry.from(ledgerTxnNo, command, line));
        }
        txn.success();
        ledgerTransactionRepository.updateStatus(txn.getLedgerTxnNo(), txn.getStatus());
        LedgerPostedEvent event = LedgerPostedEvent.of(
                UUID.randomUUID().toString(), txn.getLedgerTxnNo(),
                command.bizType(), command.bizOrderNo(), command.paymentId(), command.amount());
        outboxEventRepository.insert(OutboxEvent.pending(event));
        LedgerPostingResult result = new LedgerPostingResult(txn.getLedgerTxnNo(), txn.getStatus(), command.bizOrderNo());
        idempotencyRepository.saveSuccess(command.idempotencyKey(), "LedgerPostingService", Jsons.toJson(result));
        return result;
    }

    private void applyLine(AccountBalance balance, LedgerLineCommand line) {
        switch (line.balanceType()) {
            case AVAILABLE -> {
                if (line.direction() == EntryDirection.DEBIT && balance.getAvailableAmount().compareTo(line.amount()) < 0) {
                    throw new InsufficientBalanceException("available balance not enough");
                }
                BigDecimal delta = line.direction() == EntryDirection.DEBIT ? line.amount().negate() : line.amount();
                balance.setAvailableAmount(balance.getAvailableAmount().add(delta));
                balance.setBookedAmount(balance.getBookedAmount().add(delta));
            }
            case FROZEN -> {
                BigDecimal delta = line.direction() == EntryDirection.DEBIT ? line.amount().negate() : line.amount();
                balance.setFrozenAmount(balance.getFrozenAmount().add(delta));
            }
            default -> throw new IllegalArgumentException("unsupported balance type");
        }
    }
}

Payment‑success event consumer

@Component
public class PaymentSucceededConsumer {
    private static final Logger log = LoggerFactory.getLogger(PaymentSucceededConsumer.class);
    private final LedgerPostingService ledgerPostingService;

    public PaymentSucceededConsumer(LedgerPostingService ledgerPostingService) {
        this.ledgerPostingService = ledgerPostingService;
    }

    @KafkaListener(topics = "payment-succeeded", groupId = "accounting-service", concurrency = "6")
    public void onMessage(PaymentSucceededEvent event, Acknowledgment acknowledgment) {
        try {
            PostLedgerCommand command = PaymentLedgerCommandAssembler.from(event);
            ledgerPostingService.post(command);
            acknowledgment.acknowledge();
        } catch (DuplicateKeyException ex) {
            log.warn("duplicate payment succeeded event, paymentId={}", event.paymentId(), ex);
            acknowledgment.acknowledge();
        } catch (Exception ex) {
            log.error("consume payment succeeded failed, event={}", event, ex);
            throw ex; // let Kafka retry
        }
    }
}

Outbox publishing job

@Component
public class OutboxPublisherJob {
    private final OutboxEventRepository outboxEventRepository;
    private final KafkaTemplate<String, Object> kafkaTemplate;

    public OutboxPublisherJob(OutboxEventRepository outboxEventRepository,
                               KafkaTemplate<String, Object> kafkaTemplate) {
        this.outboxEventRepository = outboxEventRepository;
        this.kafkaTemplate = kafkaTemplate;
    }

    @Scheduled(fixedDelayString = "${outbox.publish-delay-ms:1000}")
    public void publish() {
        List<OutboxEvent> events = outboxEventRepository.findPendingBatch(100);
        for (OutboxEvent event : events) {
            try {
                kafkaTemplate.send(event.getEventType(), event.getAggregateId(), event.getPayloadJson()).get();
                outboxEventRepository.markSuccess(event.getEventId());
            } catch (Exception ex) {
                outboxEventRepository.markRetry(event.getEventId(), event.getRetryCount() + 1,
                        LocalDateTime.now().plusSeconds(5));
            }
        }
    }
}

Command assembler for payment‑success

public final class PaymentLedgerCommandAssembler {
    private PaymentLedgerCommandAssembler() {}

    public static PostLedgerCommand from(PaymentSucceededEvent event) {
        List<LedgerLineCommand> lines = List.of(
                new LedgerLineCommand(event.userWalletAccountNo(), "CASH", EntryDirection.DEBIT, BalanceType.FROZEN, event.walletFrozenAmount()),
                new LedgerLineCommand(event.userWalletAccountNo(), "CASH", EntryDirection.DEBIT, BalanceType.AVAILABLE, event.walletConfirmAmount()),
                new LedgerLineCommand("PLATFORM_RECEIVABLE", "RECEIVABLE", EntryDirection.CREDIT, BalanceType.AVAILABLE, event.totalPaidAmount())
        );
        return new PostLedgerCommand(
                event.requestId(),
                "PAY_SUCCESS:" + event.paymentId(),
                "PAY_SUCCESS",
                event.orderNo(),
                event.paymentId(),
                event.totalPaidAmount(),
                Currency.getInstance("CNY"),
                lines,
                Map.of("channelTradeNo", event.channelTradeNo())
        );
    }
}

API example (POST /api/accounting/ledger/post)

{
  "requestId": "5c9de9c2-c562-4d11-92ec-c4331f85de0b",
  "idempotencyKey": "REFUND_SUCCESS:refund_202608240021",
  "bizType": "REFUND_SUCCESS",
  "bizOrderNo": "order_202608240001",
  "paymentId": "pay_202608240008",
  "amount": 299.00,
  "currency": "CNY",
  "lines": [
    {"accountNo": "USER_1024", "subjectCode": "CASH", "direction": "CREDIT", "balanceType": "AVAILABLE", "amount": 100.00},
    {"accountNo": "CHANNEL_CLEARING", "subjectCode": "CLEARING", "direction": "DEBIT", "balanceType": "AVAILABLE", "amount": 199.00},
    {"accountNo": "PLATFORM_RECEIVABLE", "subjectCode": "RECEIVABLE", "direction": "DEBIT", "balanceType": "AVAILABLE", "amount": 299.00}
  ]
}

High concurrency & scalability – the real hard part

Hot‑account solutions

Sub‑account sharding – split a logical total account into many physical sub‑accounts (e.g., PLATFORM_RECEIVABLE_00 … PLATFORM_RECEIVABLE_15) and route by order or payment hash.

Flow‑first, balance‑async aggregation – write only flows for ultra‑high‑throughput internal pools, aggregate balances later (not suitable for user‑visible balances).

Account‑level routing units – route all data of a single user to a dedicated shard; cross‑user transactions go through a clearing layer.

Message ordering vs throughput

Kafka key = accountNo (or stable routing key).

All events for the same account land in the same partition; consumer concurrency does not exceed partition count.

Parallelism across different accounts, serial processing within one account.

Database scaling strategy

Single‑DB sharding – split ledger_entry by time or account_no.

Account‑dimension sharding – route account_balance and ledger_entry by hash of account_no.

Hot‑cold layering – keep recent 3‑6 months of flows online; archive older flows to object storage or OLAP.

Routing key priority should be account, not order, because balance updates and reconciliation revolve around accounts.

Thread‑pool & connection‑pool isolation

API thread pool.

MQ consumer thread pool.

Scheduled task thread pool.

Database connection pool.

External channel HTTP connection pool.

Write path must not share the same pool with reporting queries; channel callbacks and internal compensation should not compete for DB connections; reconciliation jobs must be rate‑limited.

Exception handling & consistency governance

Duplicate payment callbacks.

Callback arrives after order timeout closure.

Accounting succeeds but MQ send fails.

MQ sent but downstream consumer fails.

Balance update succeeds but flow write fails.

Deadlock in multi‑account transfer.

Refund and original payment confirm concurrently.

Channel reports success while internal processing stays pending.

Why "local transaction + outbox" beats "send MQ then DB"

MQ sent, DB not committed – lost fund.

DB committed, MQ not sent – lost notification.

Outbox guarantees that a successful business transaction always writes an event record; MQ delivery becomes a retryable, observable, compensable downstream step.

Compensation principle – always go through the standard accounting capability; each compensation request carries its own requestId and idempotencyKey, plus pre‑change snapshot, reason, and operator information.

Observability & operations

Logging fields (always included)

traceId

requestId

ledgerTxnNo

bizOrderNo

paymentId

accountNo

eventId

Key metrics

Posting success rate.

P95 / P99 posting latency.

Kafka consumer lag.

Idempotency hit rate.

Balance‑update failure count.

Outbox pending volume.

Accounting discrepancy count.

Automatic compensation success rate.

Tracing identifiers

orderNo

paymentId

ledgerTxnNo

channelTradeNo

Alerting examples

Continuous failures of a specific accounting event type.

Outbox backlog exceeds threshold.

Kafka consumer lag spikes.

Daily accounting discrepancy surge.

Repeated balance‑insufficient or version‑conflict on a particular account.

Security & governance

Interface security

All accounting APIs enforce authentication and signature verification.

Business parties cannot pass fields that directly affect accounting direction.

Amount, currency, and business type must pass whitelist validation.

Data security

Sensitive account information is masked in displays.

Audit logs are stored separately.

Backend UI separates query, compensation, and export permissions.

Release governance

Gradual (gray) releases.

Dual‑write or shadow traffic verification.

Feature flags for new accounting rules.

Strict rollback plans and fast recovery mechanisms.

Evolution roadmap

Stage 1 – Wallet embedded in order domain : suitable for early, low‑traffic, single‑payment‑method systems; problems quickly surface as business rules grow.

Stage 2 – Split out payment service : needed when multiple channels appear and callback management becomes complex.

Stage 3 – Build unified accounting center : required when many business lines share accounts and need standardized balance, flow, refund, compensation, and reconciliation.

Stage 4 – Sharding, unitization, settlement integration : for massive user and flow scale; adopt per‑account sharding, hot‑cold layering, and integrate with settlement/clearing systems.

Conclusion – removing the wallet from the order removes risk

Order domain – business state.

Payment domain – channel interaction.

Wallet domain – account capability.

Unified accounting center – fund facts.

A mature fund architecture exhibits these traits:

Flows are facts; balances are snapshots.

All fund changes enter through standardized posting.

Idempotency, retry, compensation, and reconciliation are core capabilities.

Main path pursues high throughput; exception path focuses on recoverability.

Engineering governance, audit tracing, gray releases, and monitoring are baked in from day one.

If your system is still at the "order directly changes balance" stage, the priority is not to add more middleware but to clarify domain boundaries first and then funnel all accounting into a unified center. The real moat of a fund system is a clear model, strict invariants, and the ability to restore correctness after failures.