For the past couple of years, the use of microservices architecture has gained serious traction in the software development industry. I can attribute this to its ability to break down complex applications into smaller, manageable applications. This architectural style allows teams to develop, deploy, and scale services independently thus increasing software development speed and scalability. On the other hand, monolithic architectures involve building applications as a single, tightly integrated unit. While monolithic architectures seem to simplify initial development and deployment speeds, they often encounter challenges as the application grows. These challenges can include limited scalability and tight coupling between modules. This is something that a microservices architecture has the ability to addresses.
Let’s explore how at Kakbima we’ve leveraged GraphQL within our microservices architecture to achieve scalability, flexibility, and maintainability.
Understanding microservices architecture at Kakbima
Since our platform serves as an insurance management and distribution solution to various stakeholders in the insurance industry, it handles a wide range of functionalities. These functionalities include customer management, product configuration, quotes generation, policy administration, and claims processing. To accommodate the different needs of our users, we did adopt a microservices architecture in the initial days of building our software.
At this point, our backend comprises of multiple microservices, each responsible for a specific business need. These microservices are then interconnected through a gateway, enabling seamless communication between the backend and frontend applications. This setup has allowed us to develop, deploy, and scale services independently on a need basis promoting flexibility and agility.
Our evolution from monolith to a microservices architecture
When we started building the platform back in 2018, we initially adopted a monolithic architecture with a REST API endpoint. At its point, the platform primarily targeted insurance agents, serving as a centralized hub for their operations. As our platform evolved to accommodate the evolving needs of the insurance industry, we encountered limitations with the monolithic approach.
As our customers’ needs grew so did our user base, we extended the platform to cater to additional stakeholders. We onboarded insurance brokers to facilitate distribution, followed by both business and individual policyholders seeking streamlined insurance management solutions. We later on added insurance companies keen on leveraging our platform to optimize their business operations and further collaborate with their policyholders, partner agents and brokers
Leveraging GraphQL in microservices architecture at Kakbima
To address the challenges posed by monolithic architectures and RESTful APIs, we adopted GraphQL as our primary technology of choice for building APIs. I will provide an overview on how GraphQL has been leveraged in conjunction with our microservices architecture:
1. The gateway
Our initial setup when building the platform was to expose multiple REST endpoints based on need by the frontend or our partners. This has since changed, currently each microservice has its defined GraphQL schema that encapsulates its’ data and business logic. The frontend team and our partners can then query a single GraphQL endpoint (the gateway), which orchestrates requests to the appropriate microservices and aggregates the responses.
This approach decouples API consumers from the underlying microservices, allowing us to evolve and scale services independently without impacting the platforms’ performance.
2. Schema Federation
Having multiple microservices in the backend means the platform runs in a complexly distributed environments that needs to support high availability. We make use of schema federation which provides a more decentralized approach that allows teams to work independently and own their services. This means that each microservice defines its schema, focusing on its domain-specific concerns.
Schema federation enables us to compose a holistic view of our domain, presenting a unified GraphQL API to the frontend team. By sharing common types and queries across services, we promote reusability and maintain separation of concerns while using the schema as the single source of truth.
3. Evolutionary Architecture
In the diverse landscape of the insurance industry, the ability to evolve services independently over time is crucial as different regions support different regulatory frameworks. GraphQL’s schema evolution capabilities empower us to introduce changes gradually and incrementally while ensuring that our architecture remains flexible and adaptable.
Consider a scenario where we need to introduce a new field, coverageType, to the Policy type:
type Policy {
id: ID!
policyholderName: String!
startDate: String!
endDate: String!
premium: Float!
coverageType: String # New field
}
Clients consuming our GraphQL API can dynamically discover the presence of the new coverageType field through schema introspection. This allows them to adapt their queries accordingly without any breaking changes. Existing clients can continue to function seamlessly, retrieving policy data with or without the new field based on their requirements.
4. Data aggregation and composition
We have designed our microservices architecture to have data reside across multiple services, each responsible for a specific business capability. We’ve leveraged GraphQL’s ability to aggregate and compose data from different sources enabling us to seamlessly retrieve comprehensive views of information.
For example, when we need to retrieve information about a customer’s policies, claims, and payments, we can define a single query that retrieves data from multiple microservices and aggregates it into a single response. This approach simplifies client-side data fetching and reduces the number of network requests thus improving overall system performance.
query {
customer(id: "123") {
id
name
policies {
id
startDate
endDate
}
claims {
id
date
amount
}
payments {
id
date
amount
}
}
}
5. Real-time data update with subscriptions
Immediate notification of changes, such as alerts for policy status changes or notifications for new or existing claims status changes are crucial for our users. We have made use of GraphQL subscriptions to implement real-time communication between clients and servers, allowing clients to subscribe to changes in data and receive updates as they occur.
A perfect scenario for this would be when an insurance agent wants to receive notifications for new policy applications:
subscription {
newPolicy {
id
policyholderName
startDate
premium
}
}
Whenever a new policy application is submitted, the server pushes a notification to all subscribed clients, providing details about the newly created policy. This enables real-time updates without the need for clients to continuously poll the server for changes.
6. Enhanced security and authorization
Where sensitive customer data and financial information are involved security is fundamental. GraphQL’s flexible approach to authentication and authorization allows us to implement fine-grained access control mechanisms tailored to our specific requirements while supporting the users needs.
Our use of a microservices architecture in conjunction with GraphQL has improved the way we design, develop, and deploy our insurance management and distribution platform. As we continue to refine our application architecture and adhere to best practices, Kakbima remains at the forefront of innovation in the insurance industry. With a relentless focus on meeting the evolving needs of our users and stakeholders, we’re committed to further helping build a better insurance.
