Skip to content
Back to data work

Case study 05 / 06

BioFlow IoT

A real-time bioreactor telemetry pipeline.

Streams flow rate, temperature and pH readings from a Python simulator through Kafka into PostgreSQL with timestamp indexing, served by FastAPI to a React dashboard that polls every 1.5 seconds.

View on GitHub
The BioFlow IoT dashboard streaming flow rate, temperature and pH readings
Type
Real-time streaming pipeline
Data
Simulated bioreactor sensors
Dashboard refresh
Every 1.5 seconds
Code
Public on GitHub

01

The problem

A lab or bioreactor operator needs to watch flow rate, temperature and pH continuously instead of checking readings by hand at intervals.

Missing a drift in those values, even for a short window, can mean a failed batch or an unsafe condition that nobody notices.

02

What I built

BioFlow IoT simulates that monitoring problem end to end: readings are generated continuously, streamed through Kafka, stored in PostgreSQL for history, and served to a live dashboard.

  • 01

    Bio-sensor simulator

    A Python service that generates flow rate, temperature and pH readings, mocking real bioreactor fluctuation.

  • 02

    Event streaming

    Readings travel as JSON packets through a Kafka broker.

  • 03

    Database consumer

    Subscribes to the stream and writes every reading to PostgreSQL, with timestamp indexes.

  • 04

    API bridge

    FastAPI endpoints for the 50 most recent records and the single latest reading, with interactive Swagger docs.

  • 05

    Live dashboard

    A React and Tailwind CSS v4 dashboard that polls the API every 1.5 seconds.

03

How it works

Architecture

Hover a component to trace its connections.

BioFlow IoT architecture. Bio-sensor simulator feeds Kafka broker (JSON). Kafka broker feeds DB consumer (stream). DB consumer feeds PostgreSQL (write). React dashboard feeds FastAPI (poll 1.5s). FastAPI feeds PostgreSQL (SQL).
  1. 1

    Generate

    The simulator produces a new reading of flow rate, temperature and pH.

  2. 2

    Stream

    Each reading goes to Kafka as a JSON packet.

  3. 3

    Persist

    The consumer subscribes and writes each reading to PostgreSQL.

  4. 4

    Serve

    FastAPI queries PostgreSQL for the latest and recent readings.

  5. 5

    Watch

    The dashboard polls the API every 1.5 seconds and updates the metrics.

04

Tech stack and why

  • Python

    The sensor simulator and the database consumer.

  • Apache Kafka

    Event streaming between the simulator and storage.

  • PostgreSQL

    Relational storage with timestamp indexes.

  • FastAPI

    Fast, self-documenting endpoints between the database and the UI.

  • React and Tailwind CSS v4

    A responsive dashboard that polls for new metrics.

  • Docker Compose

    Starts Kafka and PostgreSQL with one command.

05

Challenges and what I learned

  • Keeping operators away from the plumbing

    Operators watch the dashboard without access to the database or the sensors. The API bridge is the only part that reads PostgreSQL.

  • Quick reads as the data grows

    Readings are stored with timestamp indexes, so fetching the latest record and recent history stays fast as the table grows.

What I learned

  • Separating producing, storing and serving data into their own services makes each one simple to run, watch and replace.

What this is and isn't

A working demonstration of the ingestion, streaming, storage and serving pattern a real lab monitoring system would use, on simulated data. There's no real hardware, no authentication on the API, no alerting and no validation beyond basic type checks.

Have something like this in mind?

Have a project, role or research opportunity in mind? Let's talk.

Book a callGet in touch