Delivery Hero · Payment Routing · In production
CaaS on one screen
A payment control plane replaced hand-built tables with schema-validated configuration. The change shipped in phases, and no consumer service stopped.
- Situation
- Payment services read their configuration from a control plane. The control plane used business contracts and fixed tables. A structural change needed control-plane code, a migration, and a compatibility check. Weak validation let bad values reach a service, which then failed to start or kept the last good value.
- Task
- A cross-team RFC had settled the direction. I wrote the internal implementation RFC and the design. I also prepared the tickets and a phased rollout for one quarter. The rollout had to keep every consumer service in operation.
- Action
- We chose PostgreSQL over MongoDB because the Fintech tribe had no MongoDB operations experience. I separated the data migration from the GUI, so the conversion could ship first. I cut the Product scope into three stages: primitives, then lists, then nested objects. I did most of the tickets and, with one colleague, the refresh SDK.
- Result
- CaaS is in production. New configuration types no longer need control-plane code, and validation rejects invalid values at data entry. Services that use the SDK take configuration updates without a restart. The results are qualitative, and I claim no incident counts or savings.
PostgreSQL, not MongoDB
The Fintech tribe had no MongoDB operations experience. The cost was operational risk, not preference.
Migration before GUI
The system converted live contracts into schemas. The new storage and SCC path could then ship before the GUI.
Three-stage scope
Product accepted three stages: primitives, then lists, then nested objects.