Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Best practices for designing a central gateway/hub for microservices communication
Parent
Best practices for designing a central gateway/hub for microservices communication
I'm currently working on an architecture for a microservices-based platform and I would like to get some feedback in this regard — best way to handle integrations between the internal microservices and external services.
Current Approach
Currently, each microservice integrates directly with the required external services, leading to repeated implementations across multiple microservices. This redundancy can complicate maintenance and increase the potential for inconsistencies.
Proposed Solution
I'm thinking of implementing a central service that will act as a gateway for all microservices within the platform. This gateway would:
- Utilize gRPC for communication, which provides better performance and support for streaming
- Route requests from any microservice to the appropriate external services, acting as a central hub (and translator) for all communication channels
- Aggregate data from multiple sources, allowing internal microservices to make a single gRPC call without needing to know the details and protocols of the external services
By having internal microservices communicate only with the gateway, I can simplify the overall design. However, I have some reservations about this approach, particularly regarding the potential for a single point of failure and performance bottlenecks for the entire platform. While there are strategies to mitigate these risks (such as implementing redundancy and scaling strategies in Kubernetes), it remains a critical consideration.
Another concern is the inherent complexity — really from any solution. The gateway must remain focused on its primary role, and if it grows too complex, it may be beneficial to break it down into smaller, more manageable components. However, I'm uncertain about how to approach this breakdown, as this was the initial starting point of my design.
Notice I don't mention anything about authentication/authorization as this is handled in a different centralized layer.
Questions
- Does this approach make sense for a microservices architecture?
- What are some best practices for implementing this?
- Are there any potential pitfalls I should be aware of, particularly when using gRPC?
Will appreciate any insights or experiences you can share regarding this design pattern!
Post
Normally gateways just do routing and maybe load balancing. That's one well-defined job that can be done well. You are adding a second job, which is to be a universal adapter.
An adapter would be easier to implement as a common library. Then you don't have to bloat the gateway with adapter logic, and the library is easier to modularize - it's unlikely that each of your microservices needs to connect to each external service.
You mentioned the issue with multiple languages but this is easily solved by creating bindings for each language. There's probably not that many languages in circulation.
If you really don't want a library, the protocol adapter should be its own microservice. This would be service whose one job is to be a man in the middle between external (routed via the gateway) and internal services. The nice thing is that you can have a single adapter, or you can break it up into separate ones as much as you want. You can assign different resources to each one, autoscale them independently, and when one adapter goes down it doesn't also kill all routing across your system. This would be more aligned with the microservice philosophy.
1 comment thread
2 comment threads