ChefsStack
Recipe platform with a vector-based recommendation engine
- Role
- Backend & recommendation engine
- Period
- 2025 — 2026
- Status
- Live
- Links
- Visit site ↗
By the numbers
<50ms<50ms - similarity query
1,000+1,000+ - interaction events processed
00 - hand-written recommendation rules
Overview
A recipe and recommendation platform where suggestions come from vector similarity instead of hand-written rules, and user interactions flow through Kafka and Redis into personalized feeds.
- Similarity queries answer in under 50ms on FastAPI + pgvector.
- 1,000+ user interaction events flow through Kafka and Redis into personalized feeds and live trending lists.
- Ingestion and serving are decoupled, so a slow model never blocks reads.
01
Problem
Rule-based recommendation ('show 5 recipes from the same category') gets boring fast and needs a new rule for every new category. The goal was an engine that recommends by semantic closeness and updates itself from user behaviour.
02
Approach
Recipes are embedded and stored in PostgreSQL with pgvector; similarity queries return in under 50ms through FastAPI. I chose pgvector over a separate vector store: one database, one backup, one transaction boundary.
User interactions (views, saves, cooks) land on Kafka as events. A consumer processes them and updates personalized feeds and live trending lists in Redis.
Ingestion and serving are fully decoupled: even if embedding generation slows down, the read path keeps serving from Redis and pgvector.
03
Architecture
- Client
- Web uygulaması
- API
- FastAPI
- Öneri servisi
- Event stream
- Kafka
- Etkileşim tüketicisi
- Data
- PostgreSQL + pgvector
- Redis (akış · trend)
- Embedding işi
04
Key decisions
- 01
pgvector instead of a separate vector database
At this scale a separate vector store adds operational weight. pgvector sits next to the relational data; joins and transactions stay natural.
- 02
Precompute trending lists in Redis
Instead of computing trends on every request, the Kafka consumer keeps the list continuously fresh. The read side just pulls a list from Redis.
Outcome
The platform is live. More than 1,000 interaction events have passed through the pipeline; recommendations update in near real time from user behaviour.
What I learned
“Precomputing recommendations and trending lists into Redis kept the read path simple and fast. Most systems that feel real-time rely on this approach.”
Related projects
- AI / MLOpen source
Mobile Price Classification
Classifying phone price tiers from hardware specifications
A classification study predicting a phone's price tier from hardware specs such as RAM, battery, screen and camera; includes a data-collection script, Jupyter analysis and a containerized prediction service.
- Python
- Pandas
- Scikit-Learn
- Jupyter
- Docker
Open - AI / MLOpen source
Traffic Accident Severity Prediction
Route-risk prediction trained on 100,000+ accident records
Route-risk prediction trained on 100,000+ historical accident records, issuing real-time alerts at 85%+ accuracy using OpenRouteService and weather APIs.
- 100K+
- accident records
- 85%+
- accuracy
- Python
- Scikit-Learn
- XGBoost
- Pandas
- Flask
- React
Open - AI / MLOpen source
Appliances Energy Prediction
Comparing regression models for smart-home energy consumption
Predicting appliance energy use from 19,735 ten-minute readings in the UCI dataset. Random Forest, XGBoost, LightGBM and linear regression were compared; LightGBM led with R² ≈ 0.76.
- 19.735
- sensor rows
- 0.76
- R² (LightGBM)
- Python
- Pandas
- Scikit-Learn
- LightGBM
- XGBoost
- Jupyter
Open