All projects

Archive · 2024

Open-API

A modular financial backend focused on API-key management, service access, asynchronous processing, and a scalable service layout.

Backend engineer

  • FastAPI
  • PostgreSQL
  • Redis
  • RabbitMQ
  • Docker

Problem

A fintech surface needed more than a single CRUD API: keys, access control, and async work had to be separate, deployable modules.

What I built

  • Split the backend into FastAPI services with PostgreSQL as the system of record.
  • Used Redis and RabbitMQ for caching and asynchronous processing.
  • Packaged services with Docker so local and deployed topologies matched.

Architecture

flowchart TB
  clients[Clients] --> gateway[FastAPI services]
  gateway --> keys[API keys and access]
  gateway --> queue[RabbitMQ]
  queue --> workers[Async workers]
  gateway --> db[PostgreSQL]
  gateway --> cache[Redis]

Outcomes

  • API-key management and service-access modules with a clear boundary from workers.
  • A layout that can grow by adding consumers rather than thickening a monolith.

Context

Open-API is a modular financial backend I built to practice — and ship — the shape I wanted for fintech services: API keys, service access, and asynchronous work as separate concerns.

There is no public product URL. The repository and this writeup are the artifact.

Modules, not a ball of routes

FastAPI services expose HTTP. PostgreSQL holds keys and access records. Redis caches. RabbitMQ carries work that should not sit on the request path. Docker is how the topology stays the same from a laptop to a host.

The point of the project was the split. A monolith can grow a /keys router. A modular backend can grow a consumer without dragging the key store into the worker, or the worker into the public API.

I would not sell this as a production fintech. I would show it as the skeleton I keep using when the real product (EasyBud, Volt Wolf) needs the same seams.