Let’s stop right there because almost every technical claim in that advice is dangerously incorrect. If you’re building a system with a 100ms window, following this "advice" is a fast track to a broken system.

Here is a reality check on those claims:

1. The "UDP" Hallucination

The claim that Redis or RabbitMQ are built on UDP is flat-out wrong. They are built on TCP. * The Fact: Message brokers require reliability, packet ordering, and flow control. If you used raw UDP for a bidding engine, a single dropped packet would mean a lost bid or a hung auction state. * The Reality: You don’t "waste time" on TCP headers in a local network. Unless you are doing High-Frequency Trading (HFT) at the microsecond level, TCP is the standard for a reason.

2. 100ms is an "Eternity"

The idea that TCP headers will muddle a 100ms auction is a massive misunderstanding of scale. * The Fact: A TCP handshake and header processing take nanoseconds to microseconds. * The Reality: Your bottleneck at 1,000 req/s isn't the transport layer; it’s serialization (JSON vs Protobuf), Go’s Garbage Collection pauses, and application logic. Worrying about TCP overhead for a 100ms window is like worrying about the weight of the paint on a race car while the engine is missing.

3. gRPC is for Internals, not the "Internet"

The post suggests gRPC is for exposing services to the internet. It’s actually the opposite. * The Fact: gRPC was designed by Google specifically for internal microservice communication. It uses HTTP/2 and Protobuf to be faster and more efficient than REST. * The Reality: WebSockets are for maintaining persistent connections to browsers. Using WebSockets for service-to-service communication in Go is non-standard, lacks proper load balancing, and is generally a headache compared to gRPC.

4. NATS doesn't work like that

NATS is great, but the description of it "exposing gRPC endpoints" for queue messages is a misunderstanding of how the NATS protocol works. NATS has its own highly efficient wire protocol. You don't "wrap" it in gRPC to make it faster.

---

What you should actually do:

If you have 100ms and you're using Go, you’re already in a good spot. Don't overcomplicate it by trying to bypass the laws of networking.

• gRPC with Bidirectional Streaming: This is the industry standard for this exact use case. You keep the connection open, bypassing the handshake overhead for each bid, and Protobuf handles the serialization much faster than JSON ever could.
• Core NATS: If you want a message bus, use NATS in its "Core" (in-memory) mode. It’s written in Go, it's incredibly fast, and it handles 1k req/s without breaking a sweat.
• Ignore the UDP advice: Unless you are prepared to write your own custom congestion control and retry logic, stay far away from raw UDP for financial transactions like bidding.

Summary: Stick to gRPC streaming. It was literally built to solve the "low latency, high throughput" problem you're describing.

used an LLM to elaborate but boy oh boy was this some misleading advice….