Minura Kariyawasam

Their API traffic had to survive a full cloud zone outage

Retail bank · Europe

They were comparing the cloud provider’s own API management service against an open source alternative, and we built the competing deployment on that same cloud ourselves. For them one test mattered: kill an entire availability zone while traffic is flowing, and nothing should fail.

Active-active across two zones, so both take live traffic and nothing sits idle as a spare. A global load balancer health-checks both and routes around whichever stops answering. Databases replicate across zones, so the surviving side works from current data rather than a restore. Gateways scale out on their own when the shifted traffic lands on them, and Kafka carries the event streams between components.

The demo was about three hours on their environment. We walked the architecture, then switched a zone off and watched. Not a single call was lost.

We won the technical evaluation and the deal moved into the sales cycle.

Active-active multi-zone · Kubernetes · Global load balancing · Cross-zone replication · Kafka

They'd been stuck on the same deployment for almost a year

Bank · Africa

The cluster was locked down in every direction. No pulling images from a registry, so every image had to be loaded onto each node by hand. Traefik as the ingress controller instead of the NGINX the charts assume. Hostnames that only resolved on their corporate DNS, so pods inside the cluster couldn’t reach them. We worked on their laptop, on their console, screen on the wall, twelve of their people watching every command.

We stood up two deployment patterns in two days. The single-node HA setup first, then rebuilt their distributed deployment from scratch on current charts rather than patching what they had.

Most of the work was tracing failures that looked like one thing and were another. An install error that pointed nowhere near the empty config field causing it. A gateway that couldn’t fetch token signing keys because the URL it derived didn’t resolve inside the cluster, which is the failure mode you hit constantly once nothing can reach the public internet.

Then their real problem. Two core banking applications on separate networks, exchanging files through four cron jobs, with no way to tell a finished file from one still being written. We replaced it with a single service holding the file for one hop instead of four. On the way in it waits until the file stops changing, because the sending application controls that write and we don’t. On the way out it stages the file, verifies it, then renames it into place, which is atomic, so a half-written file can never be picked up. Neither application had to change.

Both deployments are running and the integration is deployed in their cluster.

Air-gapped Kubernetes · Rancher · Traefik · Helm · Offline image distribution · Idempotent file transfer

Remote desktop sign-in on a network with no internet

Power utility · Middle East

Fully offline network. No cloud, no outbound calls, hostnames resolving only on their own DNS. Which means every assumption a modern identity stack makes about reaching a well-known endpoint is wrong.

The identity provider runs inside the isolated zone, authenticating against the Active Directory they already run. The only route in is a site-to-site VPN.

Federation and MFA are configuration on that same server rather than new components, so they can add them later without rebuilding anything. That mattered more than it sounds: in an environment like theirs, every new component is a separate security approval.

Delivered.

Air-gapped identity · Active Directory · Site-to-site VPN · Offline OIDC

One identity platform for 15 million users, on the OpenShift they already had

National energy company · South Asia

They were consolidating identity for fuel dealers and consumers onto one platform. Their question was never about features. It was operational: will this run on the OpenShift clusters we already have, without Redis or any new middleware our team has to look after.

We onboarded accounts in bulk over SCIM2, so existing accounts came across without anyone writing migration code. Dealers manage their own staff through delegated administration, which keeps 70,000 organisations out of the central IT queue. Single sign-on over OIDC with MFA on top, all on their own infrastructure with nothing added underneath.

That was the thing blocking adoption, and it got answered. Phase one is delivered.

OpenShift · SCIM2 · OIDC · MFA · Multi-tenant identity · Delegated administration

One gateway in front of REST, SOAP, GraphQL, and a mainframe

Law-enforcement agency · Middle East

Very different systems behind one front door. Modern REST and GraphQL services, older SOAP endpoints, and a mainframe reached over a TLS connector.

Messaging between systems is point-to-point with retries, and anything that can’t be delivered goes to a dead-letter queue for inspection rather than getting lost. Person records are filtered by role, so each caller only sees the fields their role allows, enforced at the gateway rather than trusted to each backend. That last part is the pattern that matters most once non-human callers enter the picture: the policy sits in front of the data, not inside every system behind it.

Delivered.

API gateway · Mainframe integration · GraphQL · Dead-letter queues · Attribute-based filtering

Their apps were too old to rewrite, but they needed SSO

Social security institution · Latin America

Three applications on JSF and JSP, some more than a decade old, all checking credentials directly against Oracle. Rewriting them was never going to happen.

We put a containerised single sign-on layer in front instead. Each application delegates login to the identity provider, which authenticates against the same Oracle user store the applications have always trusted. The application code stays exactly as it is, and users get one login across all three.

Demonstrated and moved into their sales cycle.

Containerised SSO · Token-based delegation · Legacy modernisation