~/fozooni/about
00Profile

I build systems that have to keep running when nobody is watching them.

Backends under real load, the pipelines that feed them, and the models sitting on top. Eight years of it. Most of the time I carry the thing from ingestion to interface myself, because the handoff in the middle is where products quietly lose a month.

Based
Istanbul, Türkiye
Shipping since
8+ years
Also been
CTO, for a stretch
Studied
Computer Eng, Tehran
Speaks
English, Persian, Turkish
01

The work

Ingestion to interface,

without a handoff

My centre of gravity is backend and distributed systems. Queues, fan out, retries, idempotency: the parts nobody puts in a demo and everybody depends on at two in the morning.

I have run APIs at roughly half a million requests a minute and job pipelines chewing through about fifteen hundred background jobs a minute. Numbers like that change the design, not the hardware. They decide where a queue goes, what is allowed to fail, and which write you are willing to make twice.

The AI work is not adjacent to any of that. It runs on the same infrastructure. Agent flows, RAG pipelines, embedding based ranking, fine tuning, dataset engineering, and custom model variants trained on text, vision and behaviour together. Serving real traffic, not sitting in a notebook.

There is a media side too, which is unusual and I enjoy it. CUDA enabled FFmpeg, GPU render pipelines, transcription, video editing that runs in a browser tab. It pairs naturally with the model work, because both live or die on throughput.

And I can build the front of it. React and Next, Vue and Nuxt, Svelte, plus Tauri or Flutter when it has to leave the browser. That is not framework collecting. A product usually needs one person who can carry it the whole way without a translation layer between two teams.

800Kreq / min
API traffic carried in production
25Kjobs / min
Background pipelines, sustained
2M+records
Moved in a single migration
8+years
Shipping, not prototyping
02

Strata

Written mostly in Python, TypeScript, PHP, Rust and SQL.

surface

01

Interface

What people actually touch

  • React
  • Next.js
  • TanStack
  • Zustand
  • Redux
  • Vue
  • Nuxt
  • Pinia
  • Svelte
  • SvelteKit
  • Tailwind CSS
  • SCSS
  • Tauri
  • Flutter
02

Service

Where the request is answered

  • FastAPI
  • Django
  • NestJS
  • Fastify
  • Express
  • Adonis
  • ElysiaJS
  • Encore
  • Symfony
  • Laravel
  • REST
  • GraphQL
03

Flow

How work moves between services

  • Kafka
  • RabbitMQ
  • BullMQ
  • Redis Pub/Sub
  • WebSockets
  • Server-Sent Events
  • backpressure
  • retries and backoff
  • idempotency
04

Data

Where it lands and how fast it comes back

  • PostgreSQL
  • NoSQL
  • Elasticsearch
  • Redis
  • Memcached
  • indexing
  • query tuning
  • caching strategy
05

Models

The AI layer, in production rather than in a notebook

  • agent orchestration
  • RAG pipelines
  • embedding ranking
  • fine tuning
  • dataset engineering
  • multimodal LLM variants
  • recommendation
  • trend detection
06

Media

Pixels and audio, usually on a GPU

  • CUDA FFmpeg
  • GPU render pipelines
  • transcription
  • Remotion
  • browser video editing
07

Platform

The ground everything else stands on

  • Docker
  • Kubernetes
  • AWS
  • Google Cloud
  • Azure
  • CI automation
  • observability
  • TDD and EDD
  • E2E testing

bedrock

03

The person

Ahmad Fozooni

I live in Istanbul. Persian is my first language, English is the one I work in, and my Turkish sits somewhere between polite and useful.

I studied computer engineering in Tehran and was being paid to write code before the degree was finished. Since then I have been the engineer writing it and, for a stretch, the person deciding what got built at all. Both jobs teach the same lesson from opposite ends: the expensive mistakes are made early, quietly, in a meeting nobody wrote down.

The portrait beside this is the same treatment as the terrain behind the page. One photograph, posterised until the shading breaks into bands, then edge detected until the bands become contour lines. It seemed like a fair way to put a person on a map.

04

Method

  • 01

    Design the failure first

    Retries, backoff, idempotency and a dead letter path get written before the happy path is finished. Almost every outage I have cleaned up was a design decision somebody made six months earlier.

  • 02

    Numbers before opinions

    Structured logs, metrics and alerts ship with the feature, not after the first incident. A claim about performance with no number attached is a preference.

  • 03

    Boring where it counts

    Anything that has to survive a bad night gets the dull, proven option. I keep the interesting choices for the places where they actually buy something.

  • 04

    Own the whole path

    I would rather understand the queue, the schema and the component that renders the result than hold one slice of it. It makes handovers short and reviews honest.