The Shiny Object Problem
Every few months, someone in our industry discovers a “revolutionary” new way for microservices to talk to each other. GraphQL federation. Event sourcing with Kafka streams. gRPC with custom interceptors. NATS JetStream. The list grows longer while the fundamental problems stay the same.
I’ve implemented most of these solutions in production. Some worked brilliantly for specific use cases. Others became maintenance nightmares that taught me expensive lessons about complexity budgets. The truth is that choosing the right communication protocol for your microservices architecture isn’t about finding the most elegant solution, it’s about finding the most boring one that actually works at scale.
After fifteen years of building distributed systems, I’ve learned that protocol decisions made in conference room whiteboards rarely survive contact with real traffic, real latency, and real human beings trying to debug things at 2 AM.
HTTP REST: Still the Boring Champion
REST over HTTP gets a lot of grief from architects who want something more sophisticated. It’s synchronous. It’s chatty. It doesn’t handle backpressure elegantly. These criticisms are all true. REST is still the best choice for most microservices communication.
Why? Because every developer on your team already understands it. Your monitoring tools speak HTTP natively. Your load balancers, CDNs, and proxy servers were built for HTTP traffic. When something breaks, and it will break, you can debug it with curl and a packet sniffer.
I’ve seen teams spend months implementing sophisticated event-driven architectures only to add synchronous HTTP calls anyway because they needed to know if an operation actually succeeded. The supposed simplicity of async messaging evaporated when they realized they needed correlation IDs, dead letter queues, and circuit breakers just to get the reliability that HTTP gives you for free.
REST isn’t perfect, but it’s predictable. In distributed systems, predictability beats cleverness every time.
When Message Queues Make Sense
Don’t misunderstand me, asynchronous messaging has its place. When you need true decoupling between services, when you’re dealing with batch processing, or when you need to survive downstream service outages gracefully, message queues are invaluable.
I’ve had great success with RabbitMQ for workload distribution and Redis for simple pub/sub scenarios. Both are mature, well-understood technologies with excellent operational tooling. They fail in predictable ways. When they do fail, you can usually figure out why.
The key is knowing when to reach for async messaging. If you’re using it because REST feels “too simple,” you’re probably making a mistake. If you’re using it to solve a specific problem that synchronous communication can’t handle elegantly, you’re on the right track.
Kafka deserves special mention here. It’s powerful, but it’s also complex enough to need its own dedicated team. Unless you’re dealing with serious event streaming requirements, think financial transactions or IoT sensor data, you probably don’t need the operational overhead that Kafka brings.
The gRPC Middle Ground
gRPC sits in an interesting middle position in the microservices communication spectrum. It gives you stronger contracts than REST, better performance than JSON over HTTP, and bidirectional streaming when you need it. The tooling has matured significantly. The generated client libraries actually work reliably now.
I’ve used gRPC successfully for high-throughput internal APIs where the performance benefits justified the added complexity. The schema evolution story is solid. The built-in load balancing capabilities are genuinely useful for service mesh environments.
But gRPC isn’t a silver bullet. It’s harder to debug than plain HTTP, and it requires more sophisticated infrastructure. Your ops team needs to understand protocol buffers. Your monitoring tools need to speak gRPC natively or you’ll be flying blind when things go wrong.
The sweet spot for gRPC is internal APIs where you control both ends of the communication. For public APIs or scenarios where you need broad language support, stick with REST.
Protocol Selection in Practice
Here’s how I actually choose communication protocols for new microservices projects. First, I start with HTTP REST for everything. This gives me a working system quickly and establishes the service boundaries clearly.
Then I measure. Where are the actual bottlenecks? Which communication paths handle the most traffic? Which failures cause the most pain? Data beats intuition every time, and you can’t get meaningful data without a working system to measure.
Only then do I consider alternatives. High-traffic internal APIs might benefit from gRPC. Background processing jobs might work better with message queues. But these changes happen incrementally, with clear success criteria and rollback plans.
The biggest mistake I see teams make is trying to solve theoretical problems with complex protocols. Your microservices don’t need to be perfectly decoupled on day one. They need to work reliably and be easy to change when requirements evolve.
What’s your experience with microservices communication patterns? I’m particularly interested in hearing about scenarios where the “boring” choice didn’t work out, or where you found that additional complexity actually paid for itself in the long run.
