How Baader Bank Uses Zilla Plus to Securely Connect Amazon MSK with External Banking Partners

‍“Zilla Plus gives us a way to make real-time data in Amazon MSK accessible through familiar APIs without exposing our Kafka infrastructure or building custom middleware for every partner. It gives us a reusable integration pattern that is secure, scalable, and much easier to operate.”

-Lotta Opderbeck | Technical Product Owner, Baader Bank

Baader Bank operates an event-driven architecture built around Amazon Managed Streaming for Apache Kafka (Amazon MSK). As external partner and regulatory integration needs expanded, the bank needed a secure way to make Kafka-backed workflows available to systems that were not Kafka-native, while keeping its brokers private and avoiding a new layer of custom integration services.

The Challenge: Extending Kafka-Based Workflows to External Banking Partners

Baader Bank uses Amazon Managed Streaming for Apache Kafka (MSK) as a core event-streaming backbone for e-invoicing and financial transaction data. Its Kafka infrastructure is deployed inside private AWS networks by design, but external banking partners still need to interact with the workflows running on it.

Many of those partner systems are built around conventional HTTPS APIs rather than Kafka-native clients.

Directly exposing Kafka brokers would expand the security boundary around Baader's streaming platform and introduce additional security and operational concerns. The alternative was to build REST-to-Kafka middleware for each integration, creating another application layer that would need to be developed, secured, deployed, scaled, monitored, and maintained.

Germany's e-invoicing requirements added urgency to establishing a repeatable integration pattern that could support both current and future partner connectivity needs.

Baader needed an approach that could:

• Keep Amazon MSK isolated inside private subnets.
• Give external partners familiar HTTPS and OpenAPI-defined interfaces.
• Support real-time delivery where streaming interactions were required.
• Apply authentication, authorization, and governance consistently.
• Avoid turning every new partner connection into another middleware development project.

The Solution: Zilla Plus as the Gateway Between Partner APIs and Amazon MSK

Baader Bank deployed Zilla Plus as a stateless gateway between external partner interfaces and its private Amazon MSK environment.

Zilla Plus runs on Amazon ECS across multiple Availability Zones, with external HTTPS traffic routed through an AWS Application Load Balancer.

Instead of requiring external applications to understand Kafka, Zilla maps application-friendly protocols directly onto Kafka interactions.

OpenAPI-defined REST operations provide standards-based interfaces for partner applications, while Server-Sent Events (SSE) support real-time delivery of Kafka-backed event streams.

The result is a protocol boundary rather than another application tier: external systems use interfaces designed for them while Baader continues using Kafka as its internal real-time backbone.

Architecture at a Glance

Amazon MSK remains private. Zilla becomes the controlled ingress and egress point for partner traffic, allowing security, routing, and governance policies to be applied before requests reach the streaming platform.

The broader deployment integrates with Baader's enterprise identity environment and AWS services for TLS, secrets management, health checks, and multi-AZ resilience.

Because Zilla Plus is stateless, gateway instances can be replaced or scaled by ECS without moving application state or introducing a separate middleware data layer.

Why Zilla

What made Zilla different was that it could connect the two sides directly.

Baader did not need to introduce a separate application service to translate between partner-facing APIs and Kafka. Zilla could expose OpenAPI-defined interfaces and SSE streams while communicating natively with Amazon MSK, combining protocol mapping, security, and routing in a stateless gateway layer.

That allowed Baader to solve the integration problem at the infrastructure layer rather than turning integration code into another application that would need to be operated long term.

The Result: A Reusable Integration Pattern Without Partner-Specific Middleware

Baader Bank did not replace an existing partner-integration platform with Zilla Plus. Zilla became the integration layer from the outset.

That distinction matters.

Rather than first building REST-to-Kafka middleware and later replacing it, Baader established a reusable gateway pattern directly between external partner protocols and its private Amazon MSK environment.

Baader avoided building the partner-specific middleware that would ordinarily sit between external APIs and Kafka.

By avoiding that middleware tier, Baader also avoided a class of application development and operational work that would otherwise have been required for each partner integration.

Instead of owning a growing set of partner-specific services, Baader can manage external connectivity through a common gateway architecture and configuration model.

With Zilla Plus, the bank can keep Kafka as its internal event-streaming backbone while exposing standards-based APIs and real-time streams to external systems without creating a separate application service for each integration.

The resulting architecture provides a reusable foundation for additional partners, workflows, and regulatory requirements:

Private Kafka infrastructure. Standards-based external APIs. Real-time streaming. One governed gateway layer.

For Baader, that means new external integration requirements can build on the same architectural pattern rather than starting another middleware project from scratch.