When you don't need Kafka: event-driven systems on AWS Lambda + SSE

The Kafka tax is real

I love Kafka. I've also seen teams of 4 try to operate it and slowly lose their minds. For most workloads under a few thousand events per second, you don't need it.

Here's the stack I've used to ship event-driven systems at Polytrade and beyond.

The shape

Producer → EventBridge → Lambda → DynamoDB → SSE → Browser

Each piece is cheap, scales automatically, and, critically, needs almost zero operational care.

Why SSE over WebSockets

For one-way server-to-client updates (transaction status, sync progress, dashboard refresh), SSE wins:

• Plain HTTP, no special infra
• Automatic reconnection in the browser
• Plays nicely with HTTP/2 multiplexing
• One less library on the client

WebSockets earn their keep only when the client also pushes frequently.

The trade-offs I'd flag

• Replay is harder than in Kafka. EventBridge + a DLQ + an S3 archive gets you 80% of the way; if you genuinely need event sourcing, you'll feel the gap.
• Ordering isn't guaranteed across Lambda invocations. Design idempotently or use FIFO SQS.
• Cold starts on Lambda still exist. For latency-critical paths, provisioned concurrency is unavoidable.

Pick the boring tool. The most expensive part of any system is the one nobody on the team understands.