Transcription pipelineFlagship

meet-transcription

A web app + worker that watches a Google Drive folder, downloads recordings, transcribes with Deepgram or a local CPU engine and stores the result in PostgreSQL.

PythonFastAPIDeepgramWhisperRedisPostgreSQLDocker

Technical reading

Quick case read

Problem

Meeting recordings land in Drive, but turning every MP4 into useful text requires downloading files, calling a provider, handling queues, persisting results and delivering TXT without blocking the UI.

Solution

The UI validates and enqueues the job; the worker downloads the file, picks Deepgram or local transcription, stores the transcript in PostgreSQL and exposes the download. Redis handles queue and global lock.

Stack

Python · FastAPI · Deepgram · Whisper

Status

Flagship

Architecture

Drive comes in, worker processes, Postgres becomes source of truth

The web service never transcribes inside the request: it only creates a pending job. The worker consumes the queue with a global lock and writes the result to the database.

Technical flow

  • Input
  • Processing
  • Queue
  • Storage
  • Output
Flowchart
Rendering flowchart…

Step-by-step flow

01Input
Google DriveMeeting recordings folder
02API
FastAPI webUI/OAuth validates and creates pending job
03Queue/lock
RedisEnqueues job_id and controls global lock
04Processing
WorkerDownloads file and orchestrates transcription
05Transcription
Deepgram or local WhisperCloud provider or local CPU engine
06Storage
PostgreSQLJobs and transcripts as source of truth
07Output
TXTDownload via UI
Diagram source (Mermaid)
Paste into any Mermaid renderer
flowchart LR
  drive["Google Drive"]
  web["FastAPI web"]
  redis["Redis"]
  worker["Worker"]
  engine["Deepgram or local Whisper"]
  postgres["PostgreSQL"]
  txt["TXT"]
  drive --> web
  web --> redis
  redis --> worker
  worker --> engine
  engine --> postgres
  postgres --> txt
1. Google Drive (Input) → FastAPI web. 2. FastAPI web (API) → Redis. 3. Redis (Queue/lock) → Worker. 4. Worker (Processing) → Deepgram or local Whisper. 5. Deepgram or local Whisper (Transcription) → PostgreSQL. 6. PostgreSQL (Storage) → TXT. 7. TXT (Output).

Stack and responsibilities

  • FastAPI

    Server-rendered UI, OAuth and job creation.

  • Redis

    Transcription queue and global execution lock.

  • PostgreSQL

    Users, settings, jobs and transcripts; source of truth.

  • Deepgram / Whisper local

    Interchangeable transcription providers.

  • Docker Compose

    Packages web, worker, migrate, Redis and Postgres.

Technical decisions

  • Postgres as truth

    Redis can go down or be wiped; pending jobs are reconciled from the database.

  • Light request

    The interface only validates and enqueues. Heavy transcription stays in the worker.

  • Explicit local vs cloud

    Deepgram gives speed/diarization; local CPU reduces per-use cost and keeps processing on owned infra.

Operations

  • documentedHealthchecks and startup order

    Postgres -> Redis -> migrate -> web/worker.

  • documentedDokploy

    Public deploy guide with domain only on the web service.

  • documentedGHCR

    Workflow publishes an image on pushes to main.

Status and next steps

  • Compile whisper.cpp multi-arch into the image.
  • Add transcript search and AI summaries.
  • Improve notifications and recording automation.

Contact

Want something similar for your process?

If there is repeated input, a manual step and an expected output, there is probably a system to design.

Talk about a project