Event-driven platforms where latency is the product: sub-second event streaming over NATS JetStream, a Fortune 500 bank’s event-driven services on Event Grid and Service Bus, a healthcare eventing backbone portable between Kafka and Pub/Sub, and a national media-streaming application re-architected for scale. Leopard Data designs the event backbone, processes the stream, autoscales on demand, and keeps the fan-out fast and ordered when it matters.
Six disciplines, every one of them shipped on a live event-driven system.
The streaming spine — Apache Kafka, AWS Kinesis, Google Pub/Sub, Azure Event Hubs, Event Grid, EventBridge, NATS JetStream, RabbitMQ, and Service Bus. Topics, partitions, consumer groups, ordering, and delivery guarantees designed for the workload, not the brochure.
Continuous transformation, not nightly batch — Spark Structured Streaming, Kinesis Data Analytics, and windowed aggregation with exactly-once semantics. Enrich, join, and aggregate events in flight, then land them in the lake or the warehouse.
KEDA scaling workloads on queue and stream depth — scale-to-zero when quiet, scale to hundreds of consumers when a burst lands. We proved this out on Kubernetes and made it the reference pattern for event-driven teams.
A vendor-neutral eventing layer so a system can move between Kafka, Pub/Sub, and EventArc without a rewrite. Built with full unit coverage so the non-functional requirements — ordering, retries, dead-lettering — survive the swap.
Change data capture, real-time download/delivery features, and live materialized views — so the dashboard, the API, and the model see the event when it happens, not on the next batch run. The fast path on top of the Big Data platform.
Streaming-application architecture for a national provider, plus IoT and edge ingest over MQTT (EMQX/HiveMQ) and Go services running on the device and in the cloud. Real-time where the network is hostile and the clock is unforgiving.
The event backbone, the portability layer, and the streaming pipeline — from a produced event to a real-time result.
For a Fortune 500 bank, producers publish domain events to a broker; consumer services subscribe by topic; and KEDA scales each consumer on its backlog — from zero when idle to many pods under burst. Services stay decoupled, and capacity follows the event rate instead of a fixed guess.
flowchart LR
PROD["Producer services -- domain events"] --> BUS["Event broker -- Event Grid, Service Bus, Kafka"]
BUS --> T1["Topic -- payments"]
BUS --> T2["Topic -- accounts"]
T1 --> KEDA["KEDA -- scale on backlog"]
T2 --> KEDA
KEDA -->|"scale 0 to N"| CONS["Consumer services -- pods"]
CONS --> STORE[("State store -- Cosmos DB, PostgreSQL")]
CONS --> DOWN["Downstream APIs and notifications"]
For a national healthcare technology platform, the eventing layer had to stay portable. We built a pub/sub abstraction — one publish/subscribe contract the application codes against, with interchangeable providers underneath. Moving from Pub/Sub to Kafka becomes a config change, not a rewrite, and the non-functional requirements are covered by tests on both sides.
flowchart TD
APP["Application services"] --> ABS["Pub/Sub abstraction -- one publish and subscribe contract"]
ABS --> P1["Provider -- Google Pub/Sub"]
ABS --> P2["Provider -- Apache Kafka"]
ABS --> P3["Provider -- EventArc"]
P1 --> SUB["Subscribers -- healthcare event consumers"]
P2 --> SUB
P3 --> SUB
SUB --> SVC["TOM components -- FHIR and HL7 services"]
Devices and apps emit a continuous event stream; a broker buffers and partitions it; Spark Structured Streaming enriches and aggregates in flight; results fan out to a real-time dashboard and an alerting path while also landing in the lakehouse for history. Fast path and durable path from the same stream.
flowchart LR
SRC["Devices and apps -- event stream"] --> BROKER["Kafka or Kinesis -- partitioned topics"]
BROKER --> STREAM["Spark Structured Streaming -- enrich and window"]
STREAM --> RT["Real-time dashboard and alerts"]
STREAM --> LAKE["Lakehouse -- durable history"]
BROKER --> RAW["Raw landing -- replay and audit"]
The streaming and eventing technologies we run — the same tools across every engagement.
Five event-driven platforms across banking, healthcare, media, insurance, and energy. All of them shipped.
As Business Solutions Architect on a 60+ person program, Leopard Data drove the technical delivery of a mainframe-to-Azure banking modernization built on event-driven services — Event Grid and Service Bus pub/sub with Cosmos DB — and stood up KEDA-on-Kubernetes demos that became the team’s reference for event-driven scaling.
For a national healthcare technology platform, Leopard Data designed the common eventing platform for inter-component communication — analyzing Kafka against Google Pub/Sub and EventArc, then building a pub/sub abstraction layer in Python and TypeScript, fully unit-tested, so the system could move providers without a rewrite.
Read the full case studyLeopard Data served as Application Architect leading a team of 8 to re-architect how a major national streaming provider delivered its experience — presenting a new C++ application architecture (with Swift, Objective-C, Java, Android, and iOS clients) that was later adopted by the internal engineering team.
On a property-risk analytics platform, Leopard Data designed a real-time download delivery feature and built the team’s reference KEDA + Kafka on Kubernetes demo — producer/consumer services in .NET showing event-driven scaling, demoed to the engineering teams as the pattern to adopt.
At National Oilwell Varco, Leopard Data led a team of 9 as scrum master building Go microservices that ran on edge devices and in the cloud for drilling-field automation — gRPC/protobuf streaming APIs, edge-to-cloud data sync over NATS, MQTT, and Kafka, and PostgreSQL behind it all, plus the SAML/Okta security architecture the services ran under.
From event backbones and stream processing to KEDA autoscaling, cloud-portable eventing, and IoT ingest, Leopard Data ships the real thing. Corp-to-Corp engagements out of Plano, TX.