Settings at Scale in Outreach: Architecture

To effectively handle settings at scale, a well-designed architecture is crucial. In our previous post we discussed which setting management requirements you should keep in mind if you want to do it at scale. Let’s explore the key actors and components involved in our settings management microservice architecture.

The main actors in this architecture are as follows:

1. Flagship: The monolithic application that we are aiming to decompose into microservices. It currently holds the settings and configurations that must be extracted and managed separately.
2. Settings Microservice: a dedicated microservice responsible for handling settings and configurations, as discussed in the introduction. It serves as the central hub for managing and distributing settings to other microservices.
3. Other Microservices: These are the various microservices that require access to settings to perform their business logic. They rely on the Settings Microservice for retrieving the appropriate settings.
4. Kafka: A powerful distributed streaming platform that acts as the technology of choice for replicating data across services. It facilitates asynchronous data replication through event publishing and ingestion. Kafka ensures reliable and scalable data replication, enabling seamless communication between microservices.

There is also a variety of protocols:

1. GraphQL: Used for communication with the frontend. GraphQL offers a flexible and efficient way to fetch specific data requirements from the frontend.
2. REST: Employed for communication between the Flagship monolith and the Settings Microservice. RESTful APIs enable straightforward interactions for retrieving and updating settings.
3. gRPC: Utilized for synchronous service-to-service calls. gRPC is a high-performance, language-agnostic remote procedure call (RPC) framework that allows efficient communication between microservices.
4. Kafka: Leveraged for asynchronous data replication. Microservices can publish and consume events via Kafka, ensuring efficient data distribution across the system.

Strangler Fig Pattern: As we adopt the Strangler Fig Pattern for decomposing the Flagship monolith, we need to ensure that any dependent processes within the Flagship continue to function when the Settings Microservice takes ownership of the settings. Therefore, we maintain double writes for a certain period to guarantee compatibility and a smooth transition.

Artistic representation of a Strangler Fig made with Midjourney 5.1

Sharing data between services:

Data Replication Considerations: While data replication via Kafka provides benefits, not all services require replicated data. Replication introduces additional architectural complexity, such as ingestion pods, conflict resolutions, and data sync monitoring. Therefore, gRPC calls are the preferred approach for:

• Services with a relatively low number of requests.
• Services that don’t need to join settings data with local tables.
• Services that require synchronous access to the latest version of the settings.

Nevertheless, data replication does bring advantages for other use cases, including:

• Tier 0 services where availability takes precedence over consistency.
• Services that expose data enriched with settings information.
• Data lakes for comprehensive data analysis.

With this architecture, the Settings Microservice provides a scalable and flexible solution for managing settings within a microservices ecosystem.

It offers a range of powerful features that enhance settings-related capabilities and simplifies the process of decomposing a monolithic system. These features include managing default settings, importing/exporting settings, GraphQL APIs, and gRPC support. Additionally, the microservice provides tools such as asynchronous data replication, shadow-read data validation monitors, and transparent handling of distributed transactions.

Overall, the Settings Microservice allows teams to efficiently manage settings at scale while ensuring data consistency and facilitating their decomposition process.

In the next section, we will dive deeper into the design considerations of the Settings Microservice and explore its core features and functionalities.