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.
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!
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
How about a library instead?
The traditional way of reducing code duplication among separate software packages is to wrap the common bits in a library and use it where ever the functionality is needed.
Each microservice would still be talking directly to the external service, but most of the code handling it would not be duplicated. This assumes that your services are written in the same language.
I would turn to extra services only after this approach starts falling short. E.g. perhaps because of complex data aggregation requirements.
1 comment thread
GraphQL instead of gRPC
Assuming you do decide to implement a gateway, I'd consider implementing it as a GraphQL API instead of plain gRPC. I feel like your usecase is almost exactly what it's intended for. It too suports streaming, plus it's just a pleasure to work with in general. Easy to document, evolve etc.
0 comment threads
1 comment thread