Lead Software Engineer · Birmingham, UK

Paul Popa

Distributed systems, cloud architecture, and AI-assisted engineering in regulated environments.

Architecture-led software engineer with experience delivering event-driven banking platforms, cloud-native batch pipelines, and AI-assisted product builds.

  • Java 21
  • Spring Boot 3
  • AWS
  • EKS
  • Terraform
  • Kafka
  • Serverless
  • Claude Code
02 / Selected work

Three systems, built for resilience.

Architecture-first delivery across fraud decisioning, financial-crime batch processing, and AI-assisted product builds.

Architecture details for client projects are discussed directly in interview, in line with confidentiality obligations.

03 / Architecture
01

Featurespace Fraud-Outbound Integration

Event-driven fraud-scoring integration (design phase)

Problem

Design a resilient real-time integration between a banking platform and a third-party machine-learning fraud-scoring engine, supporting both synchronous and asynchronous processing paths.

Architecture

Event-driven integration pattern using Kafka topics for unprocessed and processed events, with retry and failover strategies for scoring-engine and broker outages, deployed as containerised services on Amazon EKS.

Tools

  • Java 21
  • Spring Boot 3
  • Kafka
  • Amazon EKS
  • Docker
02

WLX Customer Batch

AML screening batch pipeline

Problem

Replace legacy mainframe-oriented financial crime screening infrastructure with a cloud-native AML customer screening batch pipeline.

Architecture

Serverless AWS pipeline using EventBridge-triggered orchestration, Step Functions, Lambda, AWS Glue / PySpark, Apache Iceberg state tables, S3, KMS, and Terraform-managed infrastructure across multiple environments.

Tools

  • Python
  • AWS Lambda
  • Step Functions
  • EventBridge
  • Glue
  • PySpark
  • Apache Iceberg
  • S3
  • KMS
  • Terraform
  • IAM
  • Jenkins
03

NBCC Charity Platform

AI-assisted full-stack charity website

Problem

Build and operate a production charity website for donations, authentication, and admin workflows as a solo volunteer engineer.

Architecture

Static frontend + Express / TypeScript API on AWS Fargate behind an ALB, provisioned with Terraform across staging and production. Stripe Checkout with a signature-verified, idempotent webhook as the source of truth — donations, subscriptions, refunds, and Gift Aid claimed to HMRC Charities Online — plus a magic-link donor portal, scrypt-gated admin, and a Cloudflare Worker email relay.

Tools

  • Claude Code
  • TypeScript
  • Express
  • Zod
  • Stripe
  • Docker
  • AWS Fargate
  • RDS Postgres 16
  • Terraform
  • GitHub Actions
  • Cloudflare Workers
  • Cucumber BDD
A · Platform architecture · how the site works
Browserdonor · adminstatic pages · progressive JSHTTPSALBRoute 53 · ACMExpress + TS · Fargate/ · /api · /portal · /admin/api/stripe/webhook · /health:5432RDS Postgres 16donors · donations · declarationsstripe_webhook_events · audit_logStripeCheckout · Subscriptions+ WebhooksEmail relayCloudflare WorkerHMRC Charities OnlineGift Aid claimscheckoutwebhookemailsGift Aid

Stripe connects back via its webhook → POST /api/stripe/webhook (signature-verified, idempotent).

secrets — SSM Parameter Store → task def · infra — Terraform (staging + production).

B · Donation & payment flow
Donor — /donatechoose amount / plan · Gift AidPOST /api/checkout-sessionZod validate → build sessionplan→price or inline · metadataStripe Checkout — hostedcard · BACS Direct DebitDonor payssyncasyncredirect → successthank-you (UX only)→ /api/stripe/webhooksignature verifiedsession.completeddonor + donation + declone transactionconfirmation emailvia email relay

The redirect is UX only — Stripe's webhook is the source of truth; the donation is recorded server-side, idempotently.

Gift Aid declaration (and partnership shares) captured in the same transaction.

C · Inside the Stripe webhook
POST /api/stripe/webhook▲ raw body — before JSON parserconstructEvent — HMAC verifyidempotency claimINSERT stripe_webhook_eventsON CONFLICT DO NOTHINGdispatch · event.type — one idempotent transactioncheckout.session.completed→ donor + donation + Gift Aidinvoice.paid→ recurring monthly donationcharge.succeeded→ in-person (Stripe Terminal)payment_failed · sub.updated→ dunning → lapse + notifycharge.refunded · dispute→ refund + claim adjustmentCOMMIT — state + audit_log atomicpost-commit emails · best-effortconfirmation · receipt · lapse

▲ raw body before the JSON parser · a redelivered event id is a no-op (idempotency ledger) · state + audit_log commit atomically, emails are post-commit.

04 / Engineering style

How I approach systems.

01

Architecture before implementation

Design the boundaries, data flow, and failure surface first — code follows a decided shape, not the other way around.

02

Failure modes made explicit

Retries, fallbacks, DLQs, and timeouts are first-class design concerns, not afterthoughts bolted on in production.

03

AI-assisted, engineer-owned delivery

AI accelerates build and review, but architecture, correctness, and accountability stay with the engineer.

04

Regulated environment mindset

Traceability, security boundaries, and operational resilience are treated as requirements, not features.

05 / Contact

Open to lead and principal engineering conversations.

Emailpaul.popa1995@yahoo.ro

Based in Birmingham, UK · available for lead & principal roles.

Curriculum Vitae

Full CV available on request or via the download below. Scan-to-CV friendly.

Download CV