Building a Job Application Tracker with AI-Powered Resume Analysis
Author: Ahmad Fauzan Alghifari
Source Code: GitHub Repository
Job hunting is exhausting. Keeping track of where you applied, what stage each application is at, and whether your resume is even a good fit for a role — it's a lot to manage manually.
So I built a tool for it.
Jatify is a job application tracker with a backend built in Go, backed by PostgreSQL, and powered by AI resume analysis through OpenRouter. The idea is simple: you upload your resume, add job listings you're targeting, and the system analyzes how well your resume matches each role — all asynchronously, so you're never waiting around for a response.
This post covers the backend architecture: how the layers are structured, how the job queue works, and a full breakdown of every available API endpoint. The whole thing is deployed on a Linux VPS, containerized with Docker, and ships automatically via GitHub Actions CI/CD — so every push to main goes straight to production.
1. Project Overview
- Project Title: Job Application Tracker
- Objective: Implement a system to track job applications, with AI-powered resume analysis as the primary additional feature.
- System Summary: Users interact directly with a frontend application that builds and sends requests to a REST-based backend.
2. System Architecture
Service Decomposition
The backend is structured into distinct layers, each with a clear responsibility:
| Layer | Responsibility |
|---|---|
| Handler Layer | Processes incoming HTTP requests from the frontend |
| Service Layer | Contains the core business logic for each feature |
| Repository Layer | Interacts with data entities such as the database |
| Entity | Defines the data entities used in the database |
| Job Queue / Processing* | Facilitates the job queue system and concurrent processing |
Technology Stack
- Language / Framework: Go (Gin)
- Database: PostgreSQL
- In-Memory / Queue: PostgreSQL
- Deployment: Linux VPS, Docker
- CI/CD: GitHub Actions
Database Design (Job Tracker Features)
Database Design (Job Queue Feature)
3. Job Queue Workflows
The Job Queue is used here because the AI resume analysis feature is implemented via an external endpoint (OpenRouter). Since the response from OpenRouter cannot be predicted by the system, the analysis process may have variable response times, experience failures, or time out.
Data within the job queue system is stored across two entities.
3.1 Concurrency
Queue processing is handled by N concurrent workers (goroutines). Each worker waits to be "woken up". When woken, a worker searches for jobs with a pending status to process.
Workers are woken up under two conditions:
- A new job is added to the queue
- After a set timeout period
Each time a worker is woken, it picks the first available pending job — ensuring no job is skipped or given priority over another.
3.2 Enqueue
The following is a high-level visualization of the process for adding jobs to the queue.
3.3 Requeue
The following is a high-level visualization of the process for re-adding failed jobs back into the queue.
4. Available API Endpoints
Authentication
| Method | Endpoint | Description |
|---|---|---|
POST |
/api/auth/register |
Register a new user account |
POST |
/api/auth/login |
Log in and receive a JWT token |
POST |
/api/auth/logout |
Log out of the active session |
User
| Method | Endpoint | Description |
|---|---|---|
GET |
/api/user/profile |
Retrieve the profile data of the currently logged-in user |
Application Statuses
| Method | Endpoint | Description |
|---|---|---|
GET |
/api/statuses |
Retrieve a list of all available application statuses |
Job Applications
| Method | Endpoint | Description |
|---|---|---|
POST |
/api/applications |
Create a new job application |
GET |
/api/applications |
Retrieve all applications belonging to the current user |
GET |
/api/applications/:id |
Retrieve the details of a single application by ID |
PUT |
/api/applications/:id |
Update application data (including status changes) |
DELETE |
/api/applications/:id |
Delete an application (soft delete) |
Job Listings
| Method | Endpoint | Description |
|---|---|---|
POST |
/api/jobs |
Create a new job listing entry |
GET |
/api/jobs |
Retrieve all job listings belonging to the current user |
GET |
/api/jobs/:id |
Retrieve the details of a single job listing by ID |
PUT |
/api/jobs/:id |
Update job listing data |
DELETE |
/api/jobs/:id |
Delete a job listing |
Resumes
| Method | Endpoint | Description |
|---|---|---|
POST |
/api/resumes |
Upload a new resume |
GET |
/api/resumes |
Retrieve all resumes belonging to the current user |
GET |
/api/resumes/:id |
Retrieve the details of a single resume by ID |
PUT |
/api/resumes/:id |
Update resume data |
DELETE |
/api/resumes/:id |
Delete a resume |
Resume Analysis
| Method | Endpoint | Description |
|---|---|---|
POST |
/api/resumes/:id/analyze |
Initiate an AI analysis of a resume against a specific job listing (queued) |
GET |
/api/resumes/:id/analysis/:jobid |
Retrieve the analysis result for a specific resume and job listing |
GET |
/api/resumes/:id/analyses |
Retrieve all analysis results for a single resume |
Job Queue System — Dead Letter Queue (DLQ)
| Method | Endpoint | Description |
|---|---|---|
GET |
/api/dlq |
Retrieve a list of all jobs that failed processing in the Dead Letter Queue |
POST |
/api/dlq/requeue |
Re-queue multiple failed jobs at once |
POST |
/api/dlq/:uuid/requeue |
Re-queue a single failed job by UUID |
DELETE |
/api/dlq/:uuid |
Permanently delete a single job from the Dead Letter Queue |