Most of my best war stories are event-driven. I've pushed sub-second event delivery over NATS JetStream on a production platform, wired a Fortune 500 bank’s services together with Event Grid and Service Bus, built a healthcare eventing backbone that swaps between Kafka and Pub/Sub without a rewrite, and re-architected a national media-streaming application so it could survive its own scale. My job on every one of them: pick the backbone, process the stream, scale the consumers, and keep the fan-out ordered where ordering actually matters.
Six things I get hired for — each one proven on a system that is running right now.
Apache Kafka, AWS Kinesis, Google Pub/Sub, Azure Event Hubs, Event Grid, EventBridge, NATS JetStream, RabbitMQ, Service Bus — I've run all of them in anger. The interesting work isn't picking the logo; it's getting topics, partitions, consumer groups, ordering, and delivery guarantees right for the actual workload. Choose the wrong partition key and no broker will save you.
I gave up the nightly-batch mindset a long time ago. Spark Structured Streaming and Kinesis Data Analytics let me enrich, join, and window events while they're still in flight — with exactly-once semantics where the numbers have to be right — and land the results in the lake or warehouse without maintaining a second pipeline.
I scale consumers on the one thing the broker actually knows: backlog. With KEDA I've taken workloads from zero pods when things are quiet to hundreds of consumers when a burst lands, proved the pattern out on Kubernetes myself, and handed it to teams as their reference implementation.
I've watched vendor lock-in punish enough teams to design against it on principle. My pub/sub abstraction gives the application one publish/subscribe contract with Kafka, Pub/Sub, or EventArc interchangeable underneath — and I unit-test ordering, retries, and dead-lettering on every provider, because a swap breaks on the guarantees, not the happy path.
Change data capture, real-time download and delivery features, live materialized views — the plumbing that lets a dashboard, an API, or a model see an event the moment it happens instead of after the next batch run. It's the fast lane I build on top of the Big Data platform.
I've re-architected a national provider's streaming application and pulled telemetry off field hardware over MQTT (EMQX/HiveMQ) with Go services running on the device and in the cloud. Edge work keeps you humble — the network is hostile, the clock doesn't negotiate, and retry logic is where you earn your pay.
Three architectures straight off my whiteboard — the backbone, the portability layer, and the pipeline, traced from produced event to real-time result.
On the Fortune 500 banking program, I had producers publish domain events to the broker and let consumer services subscribe by topic. The piece I pushed hardest for was KEDA: each consumer scales on its own backlog, sitting at zero pods when idle and fanning out under burst. Nobody has to guess capacity anymore — the event rate decides, and the services never learn each other's names.
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"]
A national healthcare technology platform couldn't afford to marry a single broker, so I built a pub/sub abstraction: application code targets one publish/subscribe contract, and the provider underneath is interchangeable. Moving from Pub/Sub to Kafka turned into a config change. The step most teams skip — and I refused to — is writing tests for the non-functional guarantees on every provider, because that's exactly where a swap goes wrong.
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 never stop talking, so the pipeline can't either. I let the broker buffer and partition the firehose, run Spark Structured Streaming to enrich and aggregate events in flight, and fan the results out to a live dashboard and an alerting path while the same stream lands in the lakehouse for history. One stream feeding both paths means I never reconcile two copies of the truth.
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 tech I actually reach for — the same kit from one engagement to the next.
Five event-driven platforms — banking, healthcare, media, insurance, energy — and every one of them made it to production.
I was Business Solutions Architect on a 60+ person mainframe-to-Azure banking modernization, and I argued early for event-driven services — Event Grid and Service Bus pub/sub backed by Cosmos DB. The KEDA-on-Kubernetes demos I stood up ended up as the team’s reference for event-driven scaling, which is the outcome I value most: a pattern that outlives my engagement.
A national healthcare technology platform needed one eventing spine for inter-component communication, and I owned the design. I ran the broker bake-off myself — Kafka against Google Pub/Sub and EventArc — then wrote the pub/sub abstraction layer in Python and TypeScript with full unit coverage, so changing providers would never again mean rewriting the application.
Read the full case studyAs Application Architect I led a team of 8 rethinking how a major national streaming provider delivered its experience. I presented a new C++ application architecture — with Swift, Objective-C, Java, Android, and iOS clients — and the internal engineering team adopted it after I rolled off. That engagement taught me how much of architecture is really persuasion.
On a property-risk analytics platform I designed the real-time download delivery feature, then built the reference KEDA + Kafka on Kubernetes demo with my own hands — .NET producer and consumer services showing event-driven scaling end to end — and walked the engineering teams through it as the pattern worth adopting.
At National Oilwell Varco I ran a team of 9 as scrum master shipping Go microservices for drilling-field automation, split between edge devices and the cloud — gRPC/protobuf streaming APIs, edge-to-cloud sync over NATS, MQTT, and Kafka, PostgreSQL underneath, and the SAML/Okta security architecture I put in place for the services to run under.
Event backbones, stream processing, KEDA autoscaling, portable eventing, IoT ingest — I've built each of these for real, and I'd enjoy building yours. I work remote, Corp-to-Corp.