Design250K-member electric cooperative Confidential system, demo on request

API Middleware (In Design)

A real-time integration layer that will let partners post directly to the database over a secure API, replacing batch file transfers.

API Middleware (In Design) screenshot

Team of one· Solo architect

No team, no agency, no hand-offs. I owned this project end to end:

  • Requirements
  • Architecture
  • Backend & APIs
  • Database
  • Infra & deployment
Stack
FastAPImTLSKong GatewayRedisMS SQL Server

What was broken, and what fixed it

  1. Problem: Partner data arrives in batch files, so it is never real time.

    Fix: The design has partners post directly to a planned FastAPI service, with accepted posts written to MS SQL Server.

  2. Problem: Two-way integration is not possible with one-way file drops.

    Fix: Reconciliation endpoints are planned so both sides can confirm what landed.

  3. Problem: Direct posting is only safe if strangers, retries, and bursts cannot hurt the database.

    Fix: mTLS so only partners with issued certificates connect, idempotency keys so a repeated post is never recorded twice, and rate limiting against bursts.

Approach

  • mTLS so only known partners can connect.
  • Idempotency keys and rate limiting so retries and bursts are safe.
  • Reconciliation endpoints so both sides can confirm what was posted.

What I built

  • Design for direct partner-to-database posting
  • Security model: mTLS, idempotency keys, rate limiting
  • Reconciliation endpoints

Architecture

Logic & APIs

  • FastAPI
  • Kong Gateway

Data

  • Redis
  • MS SQL Server

Infrastructure & delivery

  • mTLS
  • Network
  1. 1
    FastAPI

    Planned FastAPI service that partners post to directly, replacing batch file drops.

  2. 2
    Kong GatewayIdentityNetwork

    Kong Gateway is planned as the front door for partner traffic, with mTLS between partners and the service.

  3. 3
    SQL Server

    Accepted posts are written to MS SQL Server, with reconciliation endpoints so both sides can confirm what landed.

Engineering

  • mTLS is designed so only partners with issued certificates can connect.
  • Idempotency keys are designed to make retries safe, so a repeated post is never recorded twice.
  • Rate limiting is planned to protect the database from partner bursts.
  • Designed as the next step after the partner file platform, reusing its mapping and audit approach.

Outcome

  • The planned next step after the partner file platform, from one-way ingest to two-way integration.