Backend Engineering · Professional

Cortex API

A production-style backend and React client for a data and analytics platform, covering authentication, persistence, caching, migrations, testing and API integrations.

Context

Professional

Role

Junior Software Engineer · Infometrica Strategy

Year

2025

Stack

FastAPIPostgreSQLRedisSQLAlchemyReactDockerPytestAlembicJWT

Problem

What needed solving

Infometrica's analytics product needed a backend that could authenticate API consumers, persist their accounts and usage reliably, and stay simple enough for a small team to operate and extend, plus a client surface for the people using it day to day.

What I built

Concrete responsibilities

REST API endpoints in FastAPI covering accounts, API keys, usage logs and plan data
JWT-based session authentication and a separate API-key authentication path for external consumers
The PostgreSQL data layer through SQLAlchemy, with an Alembic migration for every schema change
Redis-backed rate limiting and short-lived state for API keys
React product surfaces on the same API: dashboard, query playground, usage logs, plan and billing, and settings
Integrations that pulled data from external sources into the platform
The Pytest suite the team used as its regression baseline
Debugging across the API, database and integration layers as features shipped

System

How it fits together

Requests hit a FastAPI router, pass through an auth dependency (JWT or API key), and are logged for usage accounting. PostgreSQL, accessed through SQLAlchemy, is the system of record for accounts, keys, plans and usage; Alembic keeps schema changes reproducible across environments. Redis holds rate-limit counters and other short-lived state. The service runs in Docker for local parity with staging, and calls out to the external systems the product's data integrations depend on.

Client

Browser or API consumer sending an authenticated request.

→

FastAPI

Routes the request, validates input, calls the right service logic.

→

Auth

JWT or API-key check before anything reaches business logic.

→

PostgreSQL

System of record for accounts, keys, plans and usage.

→

Redis

Rate limiting and short-lived state.

→

Data integrations

Outbound calls to the external systems Cortex pulls data from.

Key technical decisions

What was interesting or non-trivial

Chose Redis-backed token buckets over in-memory rate limiting.

Added an operational dependency, but kept limits consistent across multiple API instances instead of per-process.

Used Alembic migrations from the start instead of hand-syncing schema.

Slower for early schema churn, but removed staging-versus-production drift as a failure mode.

Result

What the system produced

The backend handled authentication, metering and data integrations for the product through my time on the team, with a test suite the team kept building on afterward.

What I learned

How much of a backend's reliability comes from the unglamorous parts: idempotent logging, migrations that are safe to re-run, and rate limiting that fails closed instead of open.

Next project

Outfique