Skip to content

Payments Infrastructure

KrownPay

2021 – 2024 · Part-time

Backend services, cloud infrastructure, and transaction workflows for a production payments platform.

AWSEKSKubernetesEvent-Driven MicroservicesBlockchain Monitoring

Overview

Full-Stack Developer and Blockchain Engineer at KrownPay, 2021–2024 (part-time), working across payment processing, cloud infrastructure, and blockchain transaction tracking.

Problem

The platform started as a monolith. As payment volume and feature surface grew, the monolith constrained how reliably and responsively payment processing could handle load.

Role & ownership

Led the move from a monolith to event-driven microservices, and led an AWS cost-optimization project across the platform's infrastructure.

Constraints

  • Payments infrastructure carries compliance and security requirements that shape architecture choices before performance or cost.

Not published

Specific regulatory and compliance requirements are proprietary to KrownPay and aren't detailed here.

Architecture

The move from a monolith to event-driven microservices restructured how payment processing communicated internally, improving reliability and responsiveness under load.

Infrastructure ran on AWS EKS. Adding spot instances to the cluster cut infrastructure costs by 30% while improving scaling — mixing in lower-cost capacity without sacrificing the reliability payment processing needs.

Blockchain transaction monitoring ran in real time across Solana, Ethereum, and Polygon, tracking payments as they moved on-chain, alongside the platform's transaction-tracking APIs.

KrownPay's move from a monolith to event-driven microservicesMonolith (before)migrated toEvent-driven microservicesAWS EKS + spot instancesPayment processingBlockchain monitoringSolana · Ethereum · PolygonTransaction APIs30% AWS cost reduction from spot instances on EKS

Scroll horizontally to view the full diagram.

High-level shape of the migration — internal service boundaries beyond this level are proprietary to KrownPay.

Technical decisions

Decision

Monolith → event-driven microservices

Decoupling payment processing into event-driven services improved reliability and responsiveness — a failure or slowdown in one area no longer directly blocked the rest of the system.

Decision

Spot instances added to the EKS cluster

Mixing spot capacity into the cluster around workloads that could tolerate interruption cut infrastructure costs by 30% while improving scaling.

Why not the alternative — On-demand-only capacity is simpler to reason about, but leaves that cost saving on the table for workloads that don't need guaranteed capacity.

Trade-offs

Trade-off

Spot instances for cost savings

Spot capacity can be reclaimed on short notice, so workloads placed on it need to tolerate interruption — not every part of a payments system is a safe fit for spot.

Trade-off

Event-driven microservices over a monolith

Splitting the monolith traded a single deployable for distributed-systems concerns — message ordering, eventual consistency, and more moving parts to operate.

Challenges

  • Moving a live payments system from a monolith to event-driven services without downtime meant the cutover itself, not just the target architecture, had to be engineered carefully.

Not published

Deeper specifics of the migration are proprietary to KrownPay and aren't published here.

Outcome

30%

AWS infrastructure cost reduction

  • Real-time blockchain transaction monitoring live across Solana, Ethereum, and Polygon.
  • Improved reliability and responsiveness for payment processing after the move to event-driven microservices.

Technologies

AWSEKSKubernetesEvent-Driven MicroservicesBlockchain Monitoring