Munich, Germany · +49 152 5525 4780 · Available full-time — December 2026

Khaled Aldahish Senior Backend & Product Security Engineer — Java, distributed systems & payment security.

I work where backend architecture, reliability, and product security meet — particularly in payments, fintech, and digital trading platforms.

Explore my systems → Email me

Selected engineering work

Systems, not just titles.

A few systems and engineering problems that better explain how I work than a list of technologies can.

CASE / 01

Event-driven notification platform

Independently architected and built a Kotlin/Spring Boot service that moved mobile notification delivery out of the core trading server and gave it its own reliability, device-state, and delivery boundaries.

KotlinSpring BootEventBridgeSQS FIFODynamoDBECSAPNs

Explore the designDecoupling · event ingestion · ordering · recipient processing · device state · failure recovery

Design explorerselect an engineering concern

Why split this out?

Decoupling the trading platform

Push delivery had been embedded in the core trading server. Moving it behind an event boundary let notification-specific failures, scaling, certificate handling, and feature changes evolve without sitting directly in the trading request path.

Simplified design view — selected components only.

CASE / 02

SoftPOS payment platform

Co-designed a multi-tenant backend for banks and merchants, combining payment transaction processing, processor integrations, resilient coordination, messaging, and HSM-backed cryptography.

JavaSpring BootjPOSISO 8583nexo / ISO 20022RedisKafka / RabbitMQHSM / DUKPT

Explore the hard partsDuplicate prevention · uncertain outcomes · transaction state · tenant isolation · payment cryptography · protocol abstraction

Engineering explorerproblem → decision → trade-off

How do you stop the same payment twice?

Two-tier duplicate prevention

A fast Redis coordination layer rejects most concurrent duplicates, while a database uniqueness boundary remains the source of truth. Redis improves latency and avoids wasted work, but correctness does not depend on Redis being available.

Focused mechanism view — not a complete production topology.

PRACTICE / 01

End-to-end product security & PCI engineering

Led security architecture and PCI compliance for the same SoftPOS product, translating security requirements into controls across the mobile application, backend, cryptography, service identity, network boundaries, and Kubernetes environments.

PCI MPoCPCI PINHSMDUKPTmTLSKeycloak / RBACWhite-box cryptoKubernetes

Security as a product propertyMobile protection · key lifecycle · identity & trust · infrastructure controls · certification evidence

Security scopesame product, different lens

Where does the trust boundary start?

Mobile-side protection

SoftPOS moves part of the payment acceptance boundary onto a general-purpose mobile device, so the security model cannot begin at the backend. Mobile key protection and application-side controls were treated as part of the product security architecture rather than a separate frontend concern.

Security scope view — deliberately omits sensitive implementation detail.

Side project / experiment

Turning PCI governance experience into a working product.

A smaller project than the production systems above, but useful for showing how I translate compliance requirements into concrete workflows and enforcement mechanisms.

SIDE PROJECT / 01

PCI Security Governance Portal

Rapidly prototyped with AI coding agents to track PCI MPoC and PCI PIN obligations from recurring evidence requirements through submission, independent review, and audit history.

PCI MPoCPCI PINNext.jsSupabase / PostgresMicrosoft GraphRLS

What makes it interestingObligation lifecycle · segregation of duties · evidence provenance · tamper detection · immutable audit history

Implementation was built rapidly with AI coding agents; the compliance model, workflow rules, and control decisions were driven by hands-on PCI governance experience.

Governance explorerdomain rule → enforcement

How does an obligation stay alive over time?

Evidence as a recurring lifecycle

Obligations are modeled as recurring control cycles rather than one-off tickets. When evidence becomes due, the system creates work, routes it through submission and review, records the accepted evidence, computes the next due date, and reopens rejected work instead of letting it dead-end.

Working side project — presented as a governance/product experiment, not a production-scale system.

How I think

Engineering principles I keep returning to.

The recurring concerns behind my design decisions across payments, cloud services, and security-critical platforms.

Idempotency first

Retries are normal in distributed systems. Duplicate side effects should not be.

Isolate failure

External providers, queues, and downstream dependencies should fail without dragging core workflows down with them.

Identity over trust

Security boundaries should rely on explicit identity, scoped authorization, managed secrets, and verifiable service relationships.

Model the domain

Architecture is easier to keep correct when the code reflects transaction rules and real business boundaries.

Experience

A career across backend systems and security-critical products.

From payment cryptography and SoftPOS to distributed backend services for digital energy trading.

Oct 2024 — Present

enmacc · Munich

Java Backend Engineer · part-time during M.Sc.

Build and secure core-platform features in Java/Kotlin and Spring Boot, remediate application/cloud security findings, and independently delivered the event-driven notification service shown above.

Jul 2022 — Oct 2024

Fikr Jadid

Senior Java & Security Engineer · Security & Compliance Lead

Co-designed payment-platform backend architecture and led security architecture and PCI compliance for a SoftPOS platform, while remaining hands-on in production services and transaction processing.

Sep 2021 — Jul 2022

Business Solutions for Advanced Systems

Full-Stack Software Developer · HSM Engineer

Worked on the same SoftPOS product and engineering team before the transition to Fikr Jadid, with a strong focus on payment integrations and HSM-backed security work.

Apr 2024 — Expected Dec 2026

M.Sc. Informatics

Technical University of Munich

Master's in Informatics at TUM, Munich.

2017 — 2021

B.Sc. Computer Engineering

German University in Cairo

Bachelor's in Computer Engineering at the German University in Cairo, Egypt.

Current research

Collusion mitigation in RFQ-based digital wholesale energy trading

My M.Sc. thesis at TUM studies how structurally characterized forms of collusive market manipulation can be mapped to mitigation mechanisms through the traces available to digital RFQ platforms.

DegreeM.Sc. Informatics · TUM

FocusRFQs · platform traces · market integrity

ExpectedDecember 2026

Technical stack

The tools behind the systems.

Kept compact on purpose — the case studies above show how I actually use them.

Backend

Java · Kotlin · Spring Boot · Spring Data JPA · Hibernate · Spring Security · Spring Cloud Gateway · JUnit · Mockito

Architecture

Microservices · distributed systems · event-driven architecture · REST · concurrency · fault tolerance · idempotency · multi-tenancy

Cloud & delivery

AWS ECS · SQS · EventBridge · DynamoDB · IAM · Secrets Manager · Docker · Kubernetes · OpenShift · Istio

Data & messaging

Oracle · PostgreSQL · MySQL · DynamoDB · Redis · Kafka · RabbitMQ

Security

TLS/mTLS · OAuth2/JWT · Keycloak/RBAC · HSM · DUKPT · Vault · white-box cryptography · zero-trust architecture

Payments

SoftPOS · ISO 8583 · nexo / ISO 20022 · PCI MPoC · PCI PIN · PCI DSS

Contact

Interested in backend systems that have to be correct when things go wrong?

I’m based in Munich and available for full-time opportunities from December 2026.

Email me →