CaaS — STAR account

This account uses the Situation, Task, Action, and Result (STAR) structure. It describes how I helped turn an approved direction into a production system.

Read the CaaS case study for the full system description.

For the same account on one page, read the CaaS one-screen brief.

Situation

At Delivery Hero, I worked in the Payment Routing team. We owned a control plane that supplied business configuration to payment services through Spring Cloud Config (SCC).

The existing model used business contracts and predefined database structures. Services used this configuration for different business flows and operational needs.

The model had two main limitations. First, weak validation allowed invalid data to reach consumers. This could prevent a service from starting or stop it from applying an update.

Second, changes to configuration structures required control plane code changes, database work, and compatibility checks. This made changes slow and prone to errors. Services also required a restart to load the latest configuration through the previous integration.

The Product and Operations group, called Prod-Ops, needed more control over configuration. Service teams needed more flexibility as their requirements changed.

A request for comments (RFC), approved by representatives from different teams, introduced Configuration as a Service (CaaS). It extended the existing control plane with schema-based configuration.

Task

My responsibility was to help turn the approved direction into a detailed design and a production implementation.

I contributed to the RFC and developed the internal design. This covered the data model, APIs, processing flows, observability requirements, and operational guidance.

I prepared the implementation tickets and rollout roadmap. I also worked with Product to agree on the delivery scope.

We planned delivery within one quarter. We had to introduce the new model while existing payment services continued to operate.

Action

Select storage with the team

We compared PostgreSQL with a NoSQL option such as MongoDB.

We selected PostgreSQL for the first implementation. It was already in use. MongoDB would introduce costs and operational responsibilities that the Fintech tribe had no experience managing.

Separate migration from GUI delivery

The new graphical user interface (GUI) required substantial development time. I therefore planned the first phase around existing business contracts.

We read the existing data, defined suitable schemas, and converted the data into the new model. The system created bundle versions and published them automatically.

We continued to synchronize changes from the current contracts during the transition. Consumers retrieved configuration from the new model through SCC.

This allowed us to introduce the new storage and retrieval flow before the final GUI was available.

Control the rollout

For integration with the new GUI and APIs, I selected a configuration type with few dependencies on the existing structure.

We used feature flags and started with one platform in one region or country. We then added more configuration types and expanded adoption in stages.

Agree on scope with Product

Product wanted complex structures and strict validation, including checks for field types and length limits.

I discussed the delivery constraints with Product. We agreed to support primitive field types first, then lists, and then nested objects.

Some fields required Spring Expression Language (SpEL) expressions. We initially accepted strings and validated them in the API. Later, GUI components helped staff construct expressions without knowing the syntax.

This sequence kept the first release manageable and provided a path to more complex configuration.

Implement and support service integration

I implemented almost all implementation tickets. Other team members reviewed my changes.

After the initial release, one colleague and I developed a client library, or software development kit (SDK), for service integration.

The SDK retrieved the complete configuration bundle through SCC. It detected changes locally and supplied the changed configuration to the service components that listened for those changes.

We also had to account for Spring’s refresh context behavior. Some services had tasks already in progress. The integration had to apply new configuration to new tasks without changing the configuration used by running tasks.

Result

CaaS reached production.

Service teams could introduce new configuration and change existing structures more easily. Prod-Ops gained better control over data structures that matched their business needs.

Reusable definitions reduced duplication and made configuration easier to manage. Validation helped reduce incidents related to invalid configuration.

Services that adopted the SDK could apply configuration updates without restarting the whole service.

The final GUI took longer than planned. The phased approach allowed configuration conversion and SCC integration to proceed before the GUI was complete.

These results are qualitative. I do not have verified figures for incident reduction, adoption counts, or time savings.

How the SDK protects tasks in progress

The SDK had to supply new configuration to new tasks without changing the configuration that tasks already in progress were using. We had to account for Spring’s refresh context behavior when we developed it.

The SDK takes a configuration snapshot at the point a task starts. The task reads from that snapshot for its lifetime. When a new bundle version arrives, the SDK serves the new snapshot to tasks that start afterwards. Tasks already in progress keep the snapshot they started with, so their reads stay stable until they complete.

A snapshot holds resolved configuration values. A new bundle version does not change an existing snapshot.