The Corporate Pricing Engine at Zafin is an event-driven pricing and billing platform: Spring Boot, Kafka, PostgreSQL, built around domain-driven design. It processes 2M+ transactions a day at sub-second latency. None of that happens by accident, and most of the decisions that made it possible aren't visible from the outside.
The first decision was event-driven over request/response. Pricing isn't a single synchronous calculation — a price depends on a contract, a rate card, a customer tier, and a handful of upstream systems that all change independently and asynchronously. Forcing that into a request/response chain means every pricing call blocks on the slowest upstream dependency in the chain. Publishing changes as events and letting pricing evaluators react to them independently means a rate-card update doesn't have to wait for anything downstream to be ready, and a slow or degraded upstream doesn't propagate its latency into every price lookup.
The second was adopting CQRS deliberately, not by default. Contract and deal state changes are write-heavy and transactional; pricing lookups are read-heavy and need to be fast. Splitting the write model from the read model let each scale on its own terms instead of a single shared model being tuned for neither. The less obvious payoff showed up in defect rates: separating write and read models forced bounded contexts with explicit ownership, instead of the usual sprawl of shared mutable state that multiple modules quietly depend on. Driving SOLID and CQRS adoption across the team cut defect leakage by 40% — most of that wasn't from writing better code, it was from making it structurally harder to write the kind of code that used to cause the bugs.
The clearest test of the architecture was the first production go-live of Deal Manager for ING Bank, where I was technical SPOC. 99.9% uptime on day one isn't a lucky number — it's what you get when the read path and write path are already separated so a spike on one side can't take down the other, and when rollback and rollforward procedures have been drilled ahead of time instead of improvised under pressure during the actual cutover window.
The other piece worth mentioning is the delta-processing ETL, built on Spring Batch with Kafka-based partitioning, which cut data-load time by 60%. The change wasn't a faster machine — it was processing only what had actually changed since the last run instead of reprocessing everything, and partitioning that delta by key so batch jobs run in parallel instead of serializing through a single worker. Both are unglamorous changes. Both moved the number more than anything clever would have.
The most recent addition is an AI-powered Pricing & Billing Copilot that cut L1 support resolution time by 50%. The scope is narrow on purpose: it answers "why did this price come out this way" against the system's own pricing and audit data, nothing more speculative than that. That narrowness is exactly why it works — the moment a support tool has to guess instead of look something up, the time it saves in easy cases gets eaten by the time it costs in the hard ones.
If you're wrestling with a similar problem — a pricing engine, a billing platform, or any system where correctness and throughput are both non-negotiable — that's exactly the kind of conversation a consultancy session is for.