System · fintech
Payments platform microservices — billing, notifications, crypto integrations
Backend / Platform GoGingRPCPythonFastAPIKafkaRedisPostgreSQLDocker
producer ──► outbox ──► Kafka ──► inbox dedup ──► consumer (idempotent)
│
billing ◄──gRPC──► crypto · notifications failures isolated per service Problem
A B2B payments platform needed new product capabilities — billing, email notifications, cryptocurrency integrations — without destabilizing the existing system or risking the money-critical payment path.
Approach
Designed the capabilities as separate microservices in Go (Gin) and Python (FastAPI), with gRPC for synchronous calls and Kafka for event streaming. Made money-critical flows safe under retries with idempotency keys and a producer outbox → consumer inbox dedup, and isolated failures so a slow crypto provider or a notification outage can't take down billing. Redis for caching, queues, and rate limiting.
Result
A fault-tolerant microservice architecture where new services ship without risking the core payment path — with zero double-processing of payment events under retries. Led the team of 4 engineers delivering it.
Evidence
Described in work history (Korvax, 2022–present); design decisions discussable in a call.
Available for: private walkthrough
Each service owns its data and communicates through events, so a failure in notifications or a slow crypto provider cannot take down billing. The outbox→inbox pair plus idempotency keys are what make “process this payment event exactly once” true in practice, even when delivery is at-least-once.