Hey Gophers,
I’ve been building a networking engine in Go called Breeze, and I want feedback from people who have actually fought high-concurrency systems.
This is not a wrapper around net/http.
It is built on top of gnet event-loop architecture, where everything happens inside OnTraffic.
Core idea:
Each connection is classified at the event-loop level:
-
WebSocket → bypasses HTTP parsing completely
-
HTTP → manually reassembled per connection and routed
-
Blocking work → pushed into a controlled worker pool
Design choices:
gnet-based single-reactor event loop
WebSocket fast-path (zero HTTP overhead after detection)
Per-FD HTTP buffer reassembly (sync.Map based)
Dedicated WebSocket connection registry
Custom frame parser with strict limits
Worker pool sized to avoid event-loop starvation
Easy swagger
Lots of middlewares
What this really means:
Instead of treating HTTP + WS as “framework features”,
Breeze treats them as two execution paths inside a protocol multiplexer.
The event loop decides everything.
What I want feedback on:
-
Is splitting WS/HTTP at
OnTrafficthe right long-term design? -
Would you trust manual HTTP reassembly in production at scale?
-
Where would you expect contention first: sync.Map, buffers, or worker queue?
-
What breaks first at 10k–100k concurrent connections in this model?
Repo:
Documentation:
I’m currently stress-testing edge cases and trying to break the architecture before it breaks in production.
Would appreciate real-world war stories from people who’ve built similar systems.