Why Leading Banks Choose Solace for Front-end Streaming via WebSockets

Financial services firms face a challenging technical puzzle: how do you reliably stream account updates, transaction notifications, and balance changes to millions of retail banking customers across web portals and mobile applications without drowning in infrastructure complexity? Major banks have been solving this problem with Solace for years. When your front-end applications need to display live account balances, payment confirmations, and fraud alerts to customers, the underlying streaming infrastructure becomes mission-critical. Understanding why requires examining the limitations of existing approaches and how purpose-built solutions address them.

The Kafka Gap in Retail Banking Architectures

Besides leveraging Solace to power their global event mesh, many retail banks have already invested heavily in Apache Kafka for backend event streaming. Kafka excels at analytics pipelines and event sourcing, but it doesn’t work for front-end streaming, because the Kafka protocol does not support WebSockets.

If you’re an architect, this leaves you with a difficult choice: build your own scalable, resilient, and secure WebSocket layer on top of Kafka, or choose a purpose-built solution. Building custom WebSocket infrastructure means taking on significant engineering effort for connection management, protocol translation, security, and horizontal scaling. You will need to solve slow consumer handling, implement proper authentication flows, and ensure the entire tier can handle millions of concurrent connections without becoming a bottleneck.

Fortunately, Solace offers an easy, proven solution. Solace does support WebSockets, and integrates with Kafka infrastructure via a built-in bridge. And many of the world’s leading financial institutions already run and trust Solace for enterprise-grade security, and proven scalability. This complementary approach preserves your Kafka investment while extending its reach to customer-facing applications.

Bridging the Protocol Divide

The protocol mismatch between front-end and back-end systems illustrates why this integration matters. Modern front-end components typically use JavaScript and WebSockets for displaying live data, while your backend systems publish account events using Java, Python, or C++ with enterprise messaging protocols. This mismatch creates complexity that compounds as you scale.

An event mesh built with Solace Platform handles protocol translation natively, without requiring additional proxies or plugins. Backend applications distribute events using Solace’s high-performance SMF protocol while HTML5 web apps and mobile applications can. The broker handles translation seamlessly, keeping your architecture clean and your operational burden low. This native multi-protocol support becomes even more valuable when you consider the scale retail banks must achieve.

Hierarchical Topics and Wildcard Filtering

Solace’s hierarchical topic structure provides one of the most powerful capabilities for retail banking applications: the ability to organize events into logical, filterable namespaces that consumers can subscribe to using wildcards.

Topics in Solace follow a hierarchical format using forward slashes as delimiters, enabling you to encode rich context directly into the topic string. For a retail bank, a well-designed topic taxonomy might look like this:
retail/customer/{customerId}/account/{accountId}/transaction/completed
retail/customer/{customerId}/account/{accountId}/transaction/pending
retail/customer/{customerId}/account/{accountId}/balance/updated
retail/customer/{customerId}/account/{accountId}/alert/fraud
retail/customer/{customerId}/account/{accountId}/alert/lowbalance
retail/customer/{customerId}/notification/marketing
retail/customer/{customerId}/notification/security

With this structure, a single customer’s mobile banking app can subscribe to exactly the data it needs using wildcard expressions:

The single-level wildcard (*) matches exactly one level in the hierarchy, while the multi-level wildcard (>) matches one or more levels at the end of a topic. This flexibility means front-end applications can dynamically adjust their subscriptions based on which screen the customer is viewing. When a customer opens their checking account details, the app subscribes to that specific account’s transaction feed. When they return to the dashboard, it switches to a broader subscription covering all accounts.

This approach eliminates the need for client-side filtering logic or multiple specialized endpoints. Publishers simply emit events to fully-qualified topics, and the broker routes filtered stream(s) to the appropriate subscribers based on their wildcard patterns. The result is cleaner application code, reduced network overhead, and a more responsive customer experience.

Moreover, onboarding additional applications becomes incredibly straightforward. Users can subscribe to topics that correspond to events they are interested in, eliminating the need to wait for publishers to make changes. For instance, an analytics application responsible for detecting fraud can subscribe to all customer transaction events by subscribing to the following topic: retail/customer/*/account/*/transaction/>

Scaling to Millions of Customers

Capacity planning reveals one of Solace’s most compelling advantages: a single Solace software broker supports up to 200,000 concurrent WebSocket connections, meaning you can reach one million connections with just five broker instances. Solace brokers can easily be deployed in clusters to form an event mesh and scaled horizontally as more customers are on-boarded. This allows companies to start small and gradually expand their Solace deployments with business.

For a retail bank with millions of active digital banking users, this small footprint matters enormously. Custom-built WebSocket tiers or generic message brokers often require dozens of nodes to achieve similar scale. Fewer nodes translate directly to reduced infrastructure complexity, simpler upgrades, fewer failure domains, and lower total cost of ownership. However, raw scalability alone does not satisfy banking requirements. Security architecture must be equally robust.

Reference Architecture: Secure DMZ Deployment for External Clients

Retail banks require strict network segmentation between external customers and internal systems, and the recommended deployment topology addresses this directly. Solace brokers are placed in both the internal network and the DMZ, with external clients connecting via WebSockets to DMZ brokers that bridge to internal brokers.

This design enforces a critical security principle that the bridge connection is initiated by internal brokers, ensuring no inbound connections from external components into the internal network. External clients never directly connect to internal brokers, and all external traffic terminates at the DMZ with only trusted broker-to-broker communication crossing into internal systems.

This architecture also enables independent scaling. DMZ brokers scale horizontally based on WebSocket connections, while internal brokers scale independently based on message throughput since they handle aggregated traffic rather than individual customer sessions. With the infrastructure foundation established, attention can turn to optimizing the actual customer experience.

Optimizing the Customer Experience

Two specialized features deserve attention for fine-tuning customer experience at scale, each addressing distinct challenges that emerge when streaming data to millions of devices.

• Message Eliding addresses real-time data visualization challenges. A customer’s account balance might update frequently during active transaction periods, but the mobile app only needs the current state. Message eliding lets you define throttling at the client profile level, so a banking app configured for one update per second receives exactly that. Customer devices stay responsive, and mobile apps avoid unnecessary CPU, network, and battery usage.
• On-Behalf-Of (OBO) Subscriptions enable centralized subscription management essential at retail scale. Rather than exposing your topic taxonomy to browsers and mobile apps, a subscription manager integrates with your authorization and account management systems, then issues subscriptions on behalf of each WebSocket client session. This provides topic abstraction, dynamic subscription assignment, and a single audit point for compliance teams. These features work in concert with broader security controls to create a comprehensive authorization model.

Meeting Security and Compliance Requirements

ACL profiles complete the security picture by enabling fine-grained authorization tied directly to your topic hierarchy. A customer can be restricted to subscribing exclusively to updates for accounts they own, with no possibility of receiving another customer’s data.

Combined with OBO subscriptions and the DMZ deployment model described earlier, this approach fits cleanly with internal entitlement systems and regulatory requirements. Built-in slow consumer handling ensures problematic client connections will not destabilize healthy consumers or create back-pressure on publishers, meaning operations teams do not need to hand-tune complex buffering strategies.

See It in Action

The capabilities described here are not theoretical. Watch the demo video showing a six-broker deployment handling over one million concurrent WebSocket connections streaming live data. If you are evaluating real-time streaming options for retail banking portals or mobile banking apps, especially alongside an existing Kafka deployment, reach out to discuss how these capabilities map to your specific requirements.