25 points by microserviceexpert 6 months ago flag hide 17 comments
user1 6 months ago next
This is such an interesting approach to microservices! I've been looking for a solution to make them more efficient and this might just be it.
dev2 6 months ago next
Totally agree! Plus, using gRPC for event sourcing will make the communication between microservices even faster.
dev5 6 months ago prev next
What do you think about using a pub/sub model instead? Would that make it more scalable?
dev8 6 months ago next
I would recommend defining a strict contract with your gRPC services and use forward/backward compatibility when necessary. That way, you can minimize versioning issues.
dev10 6 months ago next
That's the approach I've been using as well and it's been working great so far. I'll be intrested to hear how it goes for you.
dev16 6 months ago next
Another thing to consider is the security and authentication mechanism. You can never be too careful with that. We use JWT tokens for authentication and JSON Web Signature for identifying the service endpoints.
user17 6 months ago next
That sounds like a solid setup. I'll definitely take a look into this. Thanks for all the insights!
user3 6 months ago prev next
I'm still a bit confused about how this works. Could someone give a more detailed explanation or point me to some resources?
user4 6 months ago next
Sure! I recently wrote a blog post about this exact topic. Check it out here: [link-to-post]
user7 6 months ago next
Just read your blog post, thanks for sharing! One thing I'm wondering, how do you handle versioning with this approach?
user6 6 months ago prev next
I'm not sure, but I would think that using gRPC with event sourcing would make the communication more efficient than using a pub/sub model. Plus, it would still be scalable due to the event sourcing.
user9 6 months ago next
Thanks for the explanation! I'm going to give this a try in my next project and see how it goes.
dev14 6 months ago next
Also, be sure to use in-memory data stores like Redis or Hazelcast whenever possible. The amount of overhead for I/O operations will be significantly reduced.
user15 6 months ago next
Thanks for the protip! I'm definitely going to use Redis for caching incremental changes in the microservices state for sure.
user11 6 months ago prev next
How does this approach handle failure and error states? I imagine microservices communicating with each other can create a complex web of errors if things go wrong.
dev12 6 months ago next
That's a great point. One way to handle that is to use a circuit breaker pattern that detects when a service is misbehaving and stops sending requests to it until it's back to normal. Also, using event sourcing, you can always revert back to a previous state in case of errors.
user13 6 months ago next
Ah, interesting! I've heard of the circuit breaker pattern, but never thought about using it with microservices and gRPC. Thanks for the tip!