Context

Since May 2025 I have worked as a Senior Backend Engineer on contract through Mission.dev. The client is Masdr, an enterprise fintech and payroll platform serving large Saudi Arabian employers. The role is remote.

Payroll, bank verification and disbursement all run through this one platform. That makes correctness the main concern: a lost or duplicated message means someone is paid incorrectly.

I own end-to-end feature delivery across the Spring Boot microservices.

Constraints

• Multi-tenant, multi-database architecture.
• Strict API governance for partners and banks.
• Releases move through DEV, UAT and PROD on WebLogic.

Architecture

Requests from partners and banks enter through Apigee, which applies rate limiting, authentication and authorization policy, and request/response validation. Behind it, the payroll service and the bank verification service are Spring Boot microservices. Payroll processing, bank verification and inter-service communication run as asynchronous JMS pipelines, which lead to the tenant databases.

Splunk dashboards and alerting sit on top of all of this. The stack around it includes Jenkins and IBM UrbanCode Deploy, and releases are deployed to WebLogic across DEV, UAT and PROD.

Decisions and alternatives I rejected

Asynchronous JMS pipelines, not synchronous calls

The natural alternative is for services to call each other directly and wait for the answer. In a payroll run, that ties every step to the availability and speed of the slowest one. With a message pipeline, each step takes work from the queue at its own pace, and a step that is briefly down does not take the others with it. When the cost of a lost message is a wrong salary, that separation matters.

API governance on Apigee, not inside each service

Each Spring Boot service could enforce its own authentication, rate limits and validation. With partners and banks as callers and strict governance as a requirement, I wanted those rules in one place. On Apigee the rate limiting, auth policy and request/response validation are applied the same way to every API, and the services behind it stay focused on payroll logic.

Splunk dashboards aimed at payroll incidents, not generic monitoring

General infrastructure dashboards tell you a host or service is unhealthy. The incidents that matter here are payroll and verification incidents, so the Splunk dashboards and alerting are built around those flows, to shorten the time from alert to diagnosis.

Outcome

• Shorter time to diagnose production payroll and verification incidents.
• Tenant configuration and isolation extended as new enterprise tenants onboard.