01 / TAMINI
TAMINI · طمني
MISSING-PERSON & FOUND-PERSON IDENTIFICATION PLATFORM
Tamini is a platform for finding missing people — built on missing-person and found-person reports.
Users report a missing individual or someone who has been found. The system compares faces from both sides using an AI matching pipeline, and when a possible match is found, the reporting user is notified in real time.
- MISSING REPORTS
- FOUND REPORTS
- FACE RECOGNITION
- REAL-TIME NOTIFY
02 / Tamini in action
A missing-person report.
The core flow: a user reports a missing person, attaching details and a photo the system can match against.
AND THE FOUND SIDE
A found-person report follows the same flow — an individual found somewhere can be reported the same way. The system compares faces from missing reports against faces from found reports, and notifies both sides when a match is surfaced.
one platform · one reporting flow · two sides of the same case
03 / Authentication
A session, before the platform.
Reporting and matching are protected by an authenticated session. Users register and sign in to access the platform's endpoints.
JWT-secured · bcrypt-hashed passwords · role-based access
04 / Behind the interface
The product is the surface. The system is the work.
A single report travels through a distributed backend — an application core that owns the flows, a face AI service that does the recognition, a notification server that delivers the news, and one database that holds the data and the face vectors.
05 / System overview
One report, four services.
Before the details — the shape of the system in six steps.
- 01
WEB / MOBILE
the user reports a missing or found person
- 02
MAIN APPLICATION
Spring Boot owns the reports and the flows
- 03
DATA
PostgreSQL 16 holds the data and the face vectors
- 04
FACE AI
FastAPI turns a face photo into an embedding
- 05
MATCHING
vector similarity surfaces a possible match
- 06
RESULT
hang on to the thread — the user is notified in real time
06 / System architecture
The system map.
A distributed backend in four services. The implemented system runs single instances today; the original architecture also sketched scaling and message layers that were designed but never shipped.
- 01
USER
reporter · finder
- 02
WEB BROWSER
client
- 03
MOBILE APP
client
- 04
SPRING BOOT
main application · :8080
- 05
NODE.JS / SOCKET.IO
notification server · :3000
- 06
POSTGRESQL 16
pgVector · :5432
- 07
FASTAPI
face AI service · :8000
- 08
FACE EMBEDDING
DeepFace Facenet512
- 09
FACE VECTORS
pgVector · VECTOR(512)
- 10
VECTOR SEARCH
cosine similarity
- 11
MATCH RESULT
possible match · ≥ 0.75
- 12
REPORTER
match_found · real-time
ORIGINAL ARCHITECTURE · CONCEPTUAL / DESIGNED
drawn from the original design brief — present in the repository only as the four services above
MAIN SERVER TRAFFIC
one face-matching request, end to end- 01
USER
submits a missing-person report
- 02
MISSING REPORT
details + face photo
- 03
SPRING BOOT
:8080 validates the report
- 04
FACE AI · /extract
HTTP from the main application
- 05
FACE PROCESSING
DeepFace Facenet512 · retinaface
- 06
FACE EMBEDDING
image → vector
- 07
PGVECTOR
embedding stored · VECTOR(512)
- 08
VECTOR SIMILARITY
/match · cosine similarity · top-k
- 09
MATCH DECISION
created when score ≥ 0.75
- 10
/notify-match
HTTP webhook to Socket.IO
- 11
SOCKET.IO
:3000 emits the event
- 12
REPORTER
match_found · real-time
07 / Face matching pipeline
From a face image to a possible match.
The system does not compare photos pixel-by-pixel. It turns a face into a mathematical representation — an embedding — and compares that representation against stored vectors.
- 01
FACE IMAGE
photo from the report
- 02
FACE PROCESSING
DeepFace · retinaface detector
- 03
FACE EMBEDDING
Facenet512 → vector
- 04
VECTOR REPRESENTATION
512-dimensional embedding
- 05
VECTOR DATABASE
pgVector · stored embeddings
- 06
SIMILARITY SEARCH
cosine similarity · top-k
- 07
POSSIBLE MATCH
score ≥ 0.75 · surface to the user
- DeepFace Facenet512
- retinaface
- VECTOR(512)
- cosine similarity
- top-k
- threshold ≥ 0.75
face vectors live in pgVector inside the same PostgreSQL instance.
08 / Service split
Two worlds, one platform.
The Spring Boot application owns the platform; the FastAPI service owns the AI. Separate responsibility keeps the Python face workload out of the Java application.
SPRING BOOT
main application · :8080
- user authentication · JWT · bcrypt
- missing & found person CRUD
- match management · review flow
- orchestrates the face AI + notifications
bridge
- REST · HTTP
- /extract · /match → face AI
- /notify-match → socket.io
FASTAPI
face AI service · :8000
- face embedding extraction · Facenet512
- pgVector storage & similarity search
- ranked matching · cosine similarity
- returns possible matches to the app
node.js socket.io :3000 — the real-time notification server that pushes results to clients
09 / My role
What I engineered.
A graduation project is a team effort — this is the share I own, without claiming the rest.
TEAM LEAD
Technical direction
Coordinated the technical direction of the project and shaped the overall system architecture.
BACKEND
Spring Boot application
Built the main application — its API, authentication, and business logic — as the orchestrator of the platform.
AI ENGINEERING
Face-recognition pipeline
Engineered the FastAPI face service: embedding generation, pgVector storage and the matching logic.
SYSTEM DESIGN
Architecture
Designed the full system architecture — the services, their contracts, and the matching flow this page documents.
team scope — frontend & mobile presentation was shared across the team; the engineering above is the share this page owns.
10 / Engineering decisions
Where the system chose to be careful.
Trade-offs that shaped the backend — and an honest note about what stayed on the drawing board.
- 01
A dedicated AI service
Face work is isolated in a FastAPI service rather than embedded in the Java application, so the Python AI stack stays out of the main request path.
- 02
Vectors where the data lives
Face embeddings are stored as vectors in pgVector inside the same PostgreSQL 16 instance as the application data — one database, two jobs.
- 03
Cosine similarity, not pixels
Faces are compared as 512-dimensional embeddings with cosine similarity and ranked top-k, surfaced only above a 0.75 score threshold.
- 04
Real-time by dedicated server
A Node.js Socket.IO server owns notifications: Spring calls an internal webhook, Socket.IO broadcasts match_found to the reporter's room.
- 05
Honest about scaling
The repository ships single instances via Docker Compose — it is not horizontally scaled in implementation. Load balancing, queueing, and a Redis layer were original-architecture designs, not shipped code.
11 / Summary
A platform that connects a face to a family.
Tamini is two sides of one system: an application that owns missing and found reports, and an AI pipeline that turns a face into a vector, finds the possible match, and notifies the person who reported it.
- SPRING BOOT
- JAVA
- FASTAPI
- PYTHON
- DEEPFACE
- POSTGRESQL
- PGVECTOR
- NODE.JS
- SOCKET.IO
- DOCKER
the source
The backend repository this page documents, open to read.