DEV Community: Ahmad Fauzan Alghifari

How I Built a Job Tracker Backend with a Concurrent Job Queue in Go

Ahmad Fauzan Alghifari — Mon, 18 May 2026 04:25:03 +0000

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 — 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 is — 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

The latest() Bug That Silently Duplicated Transaction IDs in Production

Ahmad Fauzan Alghifari — Mon, 20 Apr 2026 02:05:56 +0000

TL;DR: Using Model::latest()->first() to get the "latest" record by ID is wrong. latest() orders by created_at, not by the value of your ID column. When two rows are inserted within the same second, both reads return the same record, and you get duplicate IDs.

Background

I built a simple sequential ID generator for transaction IDs. The logic was straightforward: fetch the latest record, read its code, increment the number, return the next one.

$start = "XX00000001";
$latest = Model::latest()->first();

if (!$latest || !$latest->code) {
    return $start;
}

$value = $latest->code;

if (!preg_match('/^XX\d{8}$/', $value)) {
    return $start;
}

$num = (int) substr($value, -8);
return "XX" . str_pad($num + 1, 8, "0", STR_PAD_LEFT);

It worked. Passed local and dev branch testing. Got merged into production with no issues. Then one day, a user reported duplicate IDs on different transactions.

So What Happened?

My assumption was that latest() would always return the record with the highest ID. Logically, the latest record should have the highest code, right?

Wrong. latest() in Laravel is just a shorthand for orderBy('created_at', 'desc'). It doesn't care about your ID column, it orders by created_at.

This means the correctness of the whole function depends entirely on created_at being precise enough to differentiate between records. And it wasn't.

The created_at column was storing timestamps in DD:MM:YY hh:mm:ss format. The smallest unit is seconds. If two rows are inserted within the same second — whether by two users simultaneously, or by a backend loop calling this function in rapid succession, both calls to latest()->first() return the same record. Both read the same code. Both return the same next ID.

created_at	ID generated	note
20:04:01	XX00000001
20:04:01	XX00000002
20:04:01	XX00000002	DUPLICATE
20:04:01	XX00000002	DUPLICATE
20:04:02	XX00000003
20:04:02	XX00000003	DUPLICATE

The bug wasn't in the increment logic. It was in the assumption that "latest by time" equals "latest by value."

The Fix

Instead of relying on created_at ordering, query for the actual maximum code value directly.

$start = "XX00000001";

$maxValue = Model::where('code', 'LIKE', 'XX%')
    ->max('code');

if (!$maxValue) {
    return $start;
}

$num = (int) substr($maxValue, -8);
$next = $num + 1;

return "XX" . str_pad($next, 8, "0", STR_PAD_LEFT);

max('code') operates on the actual data value, not on metadata like created_at. Regardless of when a record was inserted, this always returns the highest code in the table, which is exactly what we need.

One thing worth noting: this fix doesn't eliminate the race condition entirely. Two requests can still call this function simultaneously, both read the same max before either one writes. For a truly bulletproof solution, you'd want a database-level lock (SELECT FOR UPDATE), a UNIQUE constraint on the column to let the DB reject duplicates, or just use AUTO_INCREMENT and format on read. The max() fix is a significant improvement, but it's not atomic.

What I Should Have Done

Looking back, there were two things that would have caught this before it hit production.

1. Write automated tests that simulate concurrent calls.

The bug was triggered by calling this function inside a loop — something that can't be reproduced through the UI or by a non-technical tester. A simple test that calls the function in a loop ten times and asserts all returned IDs are unique would have caught this immediately.

2. Look at the database earlier.

I spent too long staring at the code when the code itself was innocent. The real issue was in the data structure — specifically, the precision of the created_at column. Checking the actual column type and sample data earlier would have pointed me in the right direction much faster.

The most frustrating bugs are the ones where the code does exactly what you told it to. The problem is what you assumed it would do.

How I Fixed a Correlated Subquery That Was Behaving Like an N+1 Problem in Production

Ahmad Fauzan Alghifari — Tue, 14 Apr 2026 07:36:39 +0000

What Happened

A user reported seeing no data after an absurdly long loading time in one of the procurement menus. I was maintaining an e-procurement system for a state-owned enterprise subsidiary in the mining sector and this wasn't just a UI glitch. It completely blocked the user's business process.

From the network tab, the problematic request was just sitting there with endless pending status, until it hit the server's timeout and resulted in 504, effectively sending no data to the user.

The culprit turned out to be a correlated subquery behaving exactly like an N+1 problem: common, easy to miss, and quietly fatal in production. In this post, I'll walk through how I identified the root cause and fixed it.

What is an N+1 Query Problem?

Imagine you have to fetch 500 data from the database. And then, for each of that row, you run another query to compute something like aggregations. That's 1 (the initial fetching) query plus 500 query for each computation. In production, because the data will keep growing, this would be a fatal problem.

// CLASSIC ORM N+1 EXAMPLE
// 1 query
$orders = Order::all();

// N queries — one per order
foreach ($orders as $order) {
    echo $order->supplier->name; // hits the database every single iteration
}

This commonly happens when we use ORM loops like in laravel. But N+1 problem does not happen only to ORMs. Something similar could also happen to the database query itself. Which is exactly what happened in my case.

What Actually Happened

This is a snippet of a long scope code that was implemented with laravel.

->select(
...
CASE WHEN COUNT(po_items.*) > 1 THEN
    (SELECT SUM(total_value)
     FROM po_items
     WHERE po_items.po_id = po.id) 
  END AS sum_val
...
)

Do you see the problem? Yup. Its computing an aggregation function SUM() within the select statement. So for each data that comes from the FROM keyword, let's assume we have 1000 rows, it will run that exact SUM() query for another 1000 times. This will work on small data, but in production environment and database, this query won't survive.

The Fix

->leftjoin (
  SELECT po_id,
    SUM(total_value) as sum_val
  FROM po_items
  WHERE status = 'y'
  GROUP BY po_id 
) as po_item_aggs ON po.id = po_item_aggs.po_id

-- accessing it directly
SELECT po.id, po_item_aggs.sum_val

This is what I did. Instead of doing the aggregations and the subquery inside the select statement, I moved it into another Join operations. This alone removes the computation for each row from the data source. So instead of doing 1000+ query computation, we only did one query for the computation itself.

Results

Metric	Before	After
Response time	~2 minutes / timeout	~15 seconds
HTTP status	504 Gateway Timeout	200 OK
User experience	Blank table, blocked workflow	Normal

The request that was hanging for over two minutes — or not returning at all — now resolves in around 15 seconds. That's not just a performance improvement, it's the difference between a system that works and one that doesn't.