Skip to main content

Building scalable production systems that hold up

I’m Israel, a Senior Full-Stack Engineer in Lagos, Nigeria. I work across backend, distributed systems, cloud and DevOps in FinTech, PropTech, logistics and government platforms.

Currently

Lead Senior Software / DevOps Engineer

Deityvillas (GHECS)

Experience
10+ years
Partner banks
8+
VAS billers
14+
Mobile stores
iOS + Android

The short version

Ten years shipping both sides of the stack: Java and Spring Boot, Node.js and Laravel backends paired with React and React Native clients. Most of it in systems where being approximately right is the same as being wrong.

Led a funds-transfer service across 8+ partner banks, architected in-house microservices, shipped to both app stores, and owned CI/CD and cloud infrastructure end to end.

Selected work

  • Multi-Bank Funds Transfer Service

    Led backend development of a funds-transfer service operating across 8+ partner banks, plus the mobile-money integration that extended the platform into MTN's ecosystem.
  • Biller Aggregation & Value Added Services

    Integrated 14+ VAS billers (airtime, electricity, betting) into a B2B middleware, and built the aggregation platform and reporting service underneath them.
  • Property Management Platform

    Lead software and DevOps engineer: in-house backend microservices, a React Native app on iOS and Android, an engagement model served through TensorFlow Serving, and the CI/CD and cloud infrastructure underneath all of it.
  • Freight Management Platform

    Architected a full freight management system and its Kotlin mobile application, integrating third-party tracking APIs and IoT logistics data to support dynamic delivery routing.
  • Government Procurement & Tax Automation

    Backend systems for two state tax-automation programmes, including an NLP model for extracting insight from financial data.

What six years in payments actually teaches you

Anyone can list “payment integrations” on a CV. Step through the timeout scenario, that's the part that separates running one from reading about one.

Interactive · transaction lifecycle

Pick a scenario and step through it. The interesting one is not the happy path.

The connection dies mid-flight. You do not know whether the money moved. This is the state most systems model wrong.

  • Initiated
  • Pending
  • Indeterminate (current state)
  • Settled
  • Failed
  • Resolved

Step 1 of 4

→ Request sent, socket times out

Mark the transaction indeterminate. Do not release the hold, do not fail it, do not retry it as a fresh operation.

Where this goes wrong, Treating a timeout as a failure is the single most expensive bug in payments. The retry becomes a duplicate transfer.

Provider times out

Generalised from leading backend development of a multi-bank funds-transfer service in Java and Spring Boot across 8+ partner banks, and integrating a mobile-money API and 14+ VAS billers into a B2B middleware. It describes the discipline, not any employer's implementation.

Decision log

Each record names the option that was rejected, and why.

  1. One adapter per partner institutionA transfer service spanning 8+ partner banks. Each exposes a different contract, timeout profile and definition of a settled transaction.IntegrationFault isolationJava

    Options considered

    • rejectedA shared client with per-provider configConfiguration cannot express semantic differences. One provider's success means settled, another's means accepted. That is code, not a config key.
    • chosenAn adapter per provider, owning its own mapping, timeouts and error translationOnboarding the ninth bank requires no reasoning about the first eight, and one misbehaving provider stays contained instead of becoming a platform incident.

    Consequence accepted

    More code, and deliberately so. The duplication buys isolation: per-provider circuit breaking becomes possible, and each adapter declares its provider's semantics in a place an engineer will actually read.

    Grounded in, Led backend development of the FIAP Transfer Service (Java, Spring Boot) across 8+ partner banks.

  2. Model the state you cannot observeNetwork timeouts, missing callbacks and provider-side successes that never reach you are routine at volume, not edge cases.CorrectnessDistributed systemsPayments

    Options considered

    • rejectedTwo outcomes, success and failureForces the system to guess on timeout. A wrong guess in a financial system is worse than no record at all.
    • chosenThree outcomes, with an active resolution path for the thirdThe transaction's lifecycle outlives the request that started it, so something has to own it afterwards: polling, callback handling, reconciliation.

    Consequence accepted

    A transaction is not done when the request returns. That shapes the whole service: status endpoints, bounded polling with backoff, and reconciliation as a first-class feature rather than an operations script.

    Grounded in, Streamlined financial transfer operations across 8+ partner banks; integrated MTN Mobile Money into the B2B middleware.

  3. Split the reporting path from the operational pathTwo very different questions against the same data: “did this customer's payment arrive?” and “how did this biller behave last week?”ArchitectureRead pathsNode.js

    Options considered

    • rejectedOne service, one store, both query typesDifferent latency tolerances and access patterns. The analytical query eventually degrades the operational one, usually under load.
    • chosenA dedicated reporting service alongside the aggregation platformSomeone will run an unbounded query against production data. Better that they do it somewhere that cannot affect a transfer.

    Consequence accepted

    An extra service to operate, and an explicit consistency window between the two paths, which has to be stated rather than discovered by whoever reads the numbers.

    Grounded in, Built and maintained the Biller Aggregation Platform (BAP) and its companion BAP Reporting Service (BRS) in Node.js and Java/Spring Boot.

Domains

  • FinTech

    Multi-bank transfers, mobile money, VAS billers

  • PropTech

    Property management platform & mobile app

  • Logistics

    Freight management, tracking & IoT routing

  • Government

    Procurement portal & tax automation systems

Core stack

JavaSpring BootNode.jsPHPLaravelPythonDockerCI/CDJenkins

Increasing ownership

Six phases, and steadily more of the system to answer for.

  1. 2017 – 2018Frontend Engineering
  2. 2018Full-Stack Engineering & First Team Lead
  3. 2018 – 2020Lead Full-Stack Engineering · Logistics
  4. 2020 – 2026Senior Engineering · FinTech
  5. 2023 – 2026Microservices · Government Technology
  6. 2024 – PresentLead Senior Software / DevOps Engineering · PropTechFull technical ownership: service architecture, the React Native client, an ML inference path, and the CI/CD and cloud infrastructure underneath all of it.

Recognition

  • 2025Overall Best DevOps / EngineerOnafriq
  • 2022Recognised for exceptional dedication and technical contributionsCapricorn Digital Limited / Baxi by Onafriq
  • 2022Assistant Team LeadBaxi by Onafriq
  • 2018–2020Team LeadTruckka Logistics Ltd
  • 2018Team LeadTechnovia Ltd
  • Designing Microservices for Financial Systems

    Service boundaries in a payments platform are not an architectural preference, they are a correctness decision. How money, state and failure change the usual microservices advice.

    5 min read

  • Building Reliable Payment and Transfer Integrations

    A field guide to integrating banks, mobile-money operators and billers, written from the perspective that every provider will eventually behave in a way its documentation does not describe.

    5 min read

  • Lessons From Building Production APIs

    An API is a promise you have to keep after you have forgotten making it. What ten years of building integration surfaces teaches about versioning, errors, contracts and the clients you cannot upgrade.

    5 min read

Let’s build something meaningful

Open to senior and lead engineering roles internationally, remote or relocation.