DEV Community: Jufianto Henri

Queue vs Direct Insert: What Happens When 10,000 Users Hit Your Database at Once

Jufianto Henri — Wed, 25 Feb 2026 14:00:16 +0000

I've run online exam systems before.

For a middle school with around 1,000 students, I needed a database server with 4 CPUs and 8GB RAM, plus an app server with 2 CPUs and 8GB RAM. That's a lot of hardware just for 1,000 users.

The system worked, but I kept wondering — what if I had 10,000 students? Would I need 10x the resources?

So I built two versions of an exam submission system and threw 10,000 concurrent users at them. One used direct database inserts. One used a message queue.

Direct insert failed 28% of requests. Queue-based succeeded 99.7% of the time — using way less hardware.

The Problem

If you've run an online exam system, you know how this goes. Testing with 10 users works perfectly. QA with 50 concurrent users is fine. Then exam day hits with 1,000+ students and you're just hoping the server survives.

Running exams for around 1,000 middle school students taught me that you need serious hardware just to handle everyone hitting the system at the same time. They all log in together. They all submit together. And when it lags, they all refresh together.

Here's what actually happened during one of our exams:

The moment the exam started, all 1,000 students tried to log in simultaneously. But it wasn't just them — we had no idea who else was hitting the system. Curious parents checking if the portal was up? Random people who found the URL? Someone trying to probe for vulnerabilities? All of it piled on top of our legitimate traffic.

The result? CPU spiked to 80%. RAM hit 80%. The login requests were stacking up faster than the server could process them.

I had to make an embarrassing call: ask teachers to stagger logins by class, waiting 10-15 minutes between groups. Imagine telling anxious students "please wait, the system can't handle everyone at once." Not a great look.

And that was with "only" 1,000 users on a 4 CPU / 8GB database server.

But here's what kept me up at night: What happens at 10,000 users?

At that scale, your API receives 3,000 requests per second. A typical PostgreSQL connection pool maxes out at 100 connections.

Do the math: 3,000 requests competing for 100 database connections.

I had to see this for myself.

The Test Setup

I built two identical exam submission APIs in Go:

Component	Direct Insert (Port 8080)	Queue-Based (Port 8081)
API Server	Go + Fiber	Go + Fiber
Database	PostgreSQL (1 CPU, 512MB)	PostgreSQL (1 CPU, 512MB)
Message Queue	None	NATS JetStream
Workers	None	10 concurrent workers

Notice the database specs: 1 CPU, 512MB RAM. My real exam system needed 4 CPUs and 8GB RAM for just 1,000 students. I wanted to see if architecture choices could make up for limited hardware.

Load Test Configuration

Concurrent Users: 10,000 students
Peak Load: 3,000 requests/second
Duration: 5 minutes
Tool: k6 load testing

Same traffic. Same database. Two different architectures.

Approach 1: Direct Database Insert

The straightforward approach. User submits → API writes to database → Return response.

3,000 requests fighting for 100 database connections. The other 2,900? They wait. And wait. And eventually... timeout.

Approach 2: Queue-Based Architecture

The API doesn't talk to the database at all. It just publishes a message to a queue and responds immediately. Workers consume messages in the background at whatever pace the database can handle.

The queue acts as a shock absorber. Traffic spikes hit the queue, not your database.

Results

I expected the queue to win. I didn't expect it to be a blowout.

Response Time Comparison

Metric	Direct Insert	Queue-Based	Improvement
Average	487ms	8ms	60x faster
P50 (median)	392ms	6ms	65x faster
P95	1,245ms	18ms	69x faster
P99	2,891ms	34ms	85x faster
Maximum	8,432ms	127ms	66x faster

Success Rate Comparison

Approach	Successful	Failed	Success Rate
Direct Insert	12,459	4,831	72.1%
Queue-Based	17,234	56	99.7%

With direct insert, 28% of exam submissions failed. In a real exam scenario, that's potentially thousands of students who need to resubmit, file complaints, or worse — lose their work entirely.

Database Resource Usage

Metric	Direct Insert	Queue-Based
DB Connections	98-100 (maxed out)	12-18
CPU Usage	95-100%	35-60%
Query Queue	Backed up	Smooth

The direct approach pushed the database to its absolute limit. The queue approach? The database barely noticed.

Why Did Direct Insert Fail?

Analyzing the 28% failure rate, here's the breakdown:

Error Type	Percentage	What Happened
Connection Timeout	52%	Connection pool exhausted, requests waited > 10s
Database Deadlock	23%	Too many concurrent writes, lock contention
Connection Refused	18%	Max connections reached, new ones rejected
Context Canceled	7%	Users gave up waiting

The connection pool was the bottleneck. No matter how fast your database is, it can only handle so many concurrent connections.

The User Experience Difference

Direct Insert: The Frustrating Experience

User clicks "Submit" 
    → Spinner...
    → Still waiting...
    → 3 seconds pass...
    → "Connection timeout" error

(28% of the time)

Average wait: 487ms (but often 1-3 seconds, sometimes 8+ seconds)

Queue-Based: The Smooth Experience

User clicks "Submit"
    → "Submission received!"

(Processing happens in background)
(User continues immediately)

Average wait: 8ms (consistently fast)

What This Costs in Practice

My original setup for ~1,000 users:

Database: 4 CPU, 8GB RAM
App Server: 2 CPU, 8GB RAM
Monthly cost: around $200-300
Stress level during exams: high

The queue-based test with 10,000 users:

Database: 1 CPU, 512MB RAM
Everything else: minimal
Success rate: 99.7%
The database didn't even notice the load

That's 10x the users with way less hardware.

Business Impact Comparison

Aspect	Direct Insert	Queue-Based
User Errors	28% see failures	0.3% see failures
Infrastructure	Need bigger DB for spikes	Smaller DB handles more
Exam Day Stress	Engineers on-call	System stays calm
Scalability	Linear cost increase	Efficient scaling

When to Use What

Queues aren't always the answer.

Direct insert works fine when traffic is low and predictable, you need data in the database immediately (like real-time dashboards), or you're doing mostly reads with occasional writes.

Queues make sense when you have traffic spikes, lots of concurrent writes, users who care about response time, or you can't afford to lose data. The queue gives you a buffer — it absorbs the spike and lets workers process at whatever pace the database can handle.

Think exam submissions, checkout during sales, ticket purchases, push notifications — anything where everyone hits the system at once.

How the Queue Architecture Works

Here's how it works under the hood:

1. API Layer (Fast Response)

The API receives the exam submission and publishes it to NATS JetStream. No database call here — just a message publish (~2ms).

// Pseudocode
func submitExam(c *fiber.Ctx) error {
    submission := parseRequest(c)

    // Publish to queue (non-blocking, ~2ms)
    err := nats.Publish("exam.submissions", submission)
    if err != nil {
        return err
    }

    // Immediately respond to user
    return c.JSON(Response{Status: "accepted", ID: submission.ID})
}

2. Message Queue (Shock Absorber)

NATS JetStream stores messages durably. Even if workers are slow, messages aren't lost. The queue absorbs traffic spikes and releases them at a steady pace.

3. Workers (Controlled Processing)

10 concurrent workers pull messages from the queue. Each worker processes in batches of 100 records — reducing database round trips.

// Pseudocode
func worker() {
    for {
        messages := queue.FetchBatch(100)  // Get 100 messages
        submissions := parseAll(messages)

        db.BatchInsert(submissions)  // Single DB call for 100 records

        queue.AckAll(messages)
    }
}

4. Database (Happy and Healthy)

Instead of 3,000 concurrent connections, the database sees a steady stream from 10 workers. CPU stays at 35-60%. No deadlocks. No timeouts.

What I Learned

Connection pools have hard limits. Doesn't matter how fast your database is — 3,000 requests can't share 100 connections without waiting. I learned this the hard way.

Queues trade immediate consistency for reliability. The user gets a fast "accepted" response, but the data isn't in the database yet. For most write-heavy workloads, that tradeoff is worth it.

The performance difference is huge. Not 2x or 3x — we're talking 60-85x faster response times.

Queues handle spikes gracefully. During a traffic spike, the queue just grows. Nothing crashes. When traffic drops, workers catch up. No 2 AM pages.

Architecture matters more than hardware. My 1,000-user system needed 4 CPU and 8GB RAM. This queue-based test handled 10,000 users on 1 CPU and 512MB.

Wish I'd known this earlier. Could've saved money and stress.

Wrapping Up

Queues aren't always the answer. But for traffic spikes and heavy writes? Worth considering.

Looking back at my exam systems with their beefy servers, I wish I'd tried this sooner. Usually you trade performance for cost — this gave me both.

Next time you're building something write-heavy, ask yourself: what happens when everyone hits it at once?

Code is on GitHub: jufianto/blog-resource/exam-app-queue

Further Reading

Have you dealt with database bottlenecks under load? I'd like to hear about it.

another of my blog, check it out.

Jufianto Henri — Thu, 03 Apr 2025 09:09:51 +0000

Jufianto Henri

Apr 3 '25

Fixing Select2 Issues in Laravel Livewire 3: A Frustrating but Solvable Challenge

#laravel #php #livewire #webdev

Comments

4 min read

Fixing Select2 Issues in Laravel Livewire 3: A Frustrating but Solvable Challenge

Jufianto Henri — Thu, 03 Apr 2025 08:45:08 +0000

For the past couple of months, I've been working on building a simple CMS web app using Laravel with Livewire 3. While everything was going smoothly, I encountered an issue that left me frustrated—my Select2 dropdown wasn't updating or binding data correctly in Livewire.

📌 Why Use Select2?

I chose Select2 because I needed a simple UI component for searching through a list of data within a dropdown. Select2 provides an elegant solution that enhances standard <select> elements with search functionality, without requiring me to build a custom UI from scratch.

However, integrating Select2 with Livewire 3 wasn’t as straightforward as I expected. The problem? Livewire doesn’t automatically recognize updates made by JavaScript-based components like Select2.

🚨 The Issue: Select2 and Livewire Data Binding

When using Livewire, form inputs are usually bound using wire:model, allowing real-time updates to the component state. However, since Select2 manipulates the DOM using JavaScript, Livewire doesn’t detect changes made by Select2 unless explicitly notified.

here my basic setup

Blade Component (example.blade.php)


<div>
    <form class="max-w-sm mx-auto mb-5" wire:submit.prevent="submit">
        <label for="countries" class="block mb-2 text-sm font-medium text-gray-900 dark:text-white">Select an option</label>
        <select id="countries" wire:model.live="select_value" class="bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500">
            <option selected>Choose a country</option>
            <option value="US">United States</option>
            <option value="CA">Canada</option>
            <option value="FR">France</option>
            <option value="DE">Germany</option>
        </select>

        <input class="mt-2 block mb-2" wire:model="select_value">

        <button type="submit" class="text-white bg-blue-700 px-5 py-2 rounded-md">Save</button>

    </form>
</div>


<script>
    function init_select2(){
        var ctr = $('#countries')
        ctr.select2();
    }

  $(document).ready(function (){
        // init_select2();
    });
</script>

Livewire Component (Example.php)

<?php

namespace App\Livewire;

use Livewire\Component;

class Example extends Component
{

    public $select_value = "default-value";

    public function render()
    {
        return view('livewire.example');
    }

    public function submit(){
        dd($this->select_value);
    }
}

to be able use select2 and jquery, you must include this section on your blade layout

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
<link href="https://cdn.jsdelivr.net/npm/select2@4.1.0-rc.0/dist/css/select2.min.css" rel="stylesheet" />
<script src="https://cdn.jsdelivr.net/npm/select2@4.1.0-rc.0/dist/js/select2.min.js"></script>

the code above I do comment on section init select2 and select2 should not be active or running.
here the expected result I need and this is without use select2

you see after click save button I can see result the value I selected. lets turn on and init select2 by uncomment init_select2();

you can see the result still default-value and not binding based on value select we are selected.

✅ The Solution: Manually Dispatching Events to Livewire

Since Livewire 3 doesn’t automatically detect DOM changes from JavaScript-based UI components, we need to manually update Livewire’s state when Select2 changes.

Livewire Component (Example.php)

<?php

namespace App\Livewire;

use Livewire\Attributes\On;
use Livewire\Component;

class Example extends Component
{

    public $select_value = "default-value";

    public function render()
    {
        return view('livewire.example');
    }

    public function submit(){
        dd($this->select_value);
    }

    #[On('select-updated')]
    public function updateValue($val){
        $this->select_value = $val;
        $this->dispatch("update-value");
    }
}

Blade Componenet (example.blade.php

<div>
    <form class="max-w-sm mx-auto mb-5" wire:submit.prevent="submit">
        <label for="countries" class="block mb-2 text-sm font-medium text-gray-900 dark:text-white">Select an option</label>
        <select id="countries" wire:model="select_value" class="bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500">
            <option selected>Choose a country</option>
            <option value="US">United States</option>
            <option value="CA">Canada</option>
            <option value="FR">France</option>
            <option value="DE">Germany</option>
        </select>

        <input class="mt-2 block mb-2" wire:model="select_value">

        <p class="block text-sm mb-2">value selected: {{ $select_value }}</p>

        <button type="submit" class="text-white bg-blue-700 px-5 py-2 rounded-md">Save</button>

    </form>
</div>

<script>

    function init_select2(){
        var ctr = $('#countries')
        ctr.select2();
    }

    $(document).ready(function (){
        init_select2();
        $('#countries').on("change", function (e){
            window.Livewire.dispatch('select-updated', [$(this).val()]);
        });
    });

    Livewire.on("update-value", function (){
        setTimeout(init_select2, 0)
        console.log("event udpated and reset select2")
    })

</script>

🔍 Key Fixes & Takeaways

✅ Manually dispatch the select-updated event when Select2 changes.
✅ Listen for update-value in Livewire to trigger a reinitialization of Select2.
✅ Use setTimeout(init_select2, 0); to prevent Select2 from breaking after a Livewire re-render. setTimeout is needed because it ensures that Livewire processes its updates first before re-initializing Select2.

Now, every time a user selects an option, Livewire correctly updates its state, and Select2 remains functional after re-renders! 🚀

here the result

🎯 Final Thoughts

Integrating Select2 with Livewire 3 can be frustrating, but the solution is simple once you understand how Livewire handles JavaScript-based components. By manually dispatching updates and re-initializing Select2, you can enjoy the benefits of Livewire’s reactivity and Select2’s powerful search features.

If you run into issues, try this approach and let me know how it works for you! 🚀🔥

Init your golang gRPC Services

Jufianto Henri — Sat, 09 Nov 2024 14:58:22 +0000

Hello, After so long time I'm not writing again (last time write on medium), finally I do gather the intention to make an article again. today I want to share how do I creating my grpc services from stracth.

for the context I want to create continues article, I will try to build complex system application that will mock like real world problem. but lets see later if I can complete that.

for now lets do focus on how to creating the golang grpc services, I will create really simple application and how to test it.

Install the prerequisites tools

you need to install protoc first, I used linux so to install that need to run

sudo apt install -y protobuf-compiler

how if I use macos? run this, but I'm not sure if its work because I dont have macos

brew install protobuf

if already installed, please verify by run

protoc --version

it will show the version of protoc, for me I have protoc version libprotoc 3.6.1.
after do that, install the requirement plugin protoc for golang

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

and make sure bin for protoc-gen-go and protoc-gen-go-grpc already on your path.

Path Structure

so this is my structure my project, btw this path structure will look like complicated, because I want to make continues app later in this project, so just bear with it

little breakdawn what inside the folder.
agent -> it will the base applications. basically I want to make app using state-machine pattern
agent/client -> it will hold the client type and the handler for GRPC
proto -> this will based proto files for our grpc. the files *.pb.go and *_grpc.pb.go will generated automaticall, we just need to write .proto files for service definition of rpc

Make your syntax proto

Lets make your syntax proto

proto/agent.proto

syntax = "proto3";
option go_package = "github.com/jufianto/state-agent/agentsrv-proto";

enum TaskStatus{
    UNKNOWN = 0;
    PROCESSING = 1;
    FAILED = 2;
    SUCCESS = 3;
}

message TaskRequest{
    string task_id = 1;
    string task_name = 2;
    string task_url = 3;
}

message TaskResponse{
    string task_id = 1;
    string task_result = 2;
    TaskStatus task_status = 3;

}

message TaskListResponse{
    repeated TaskResponse tasks = 1;
}

message TaskListRequest{
    repeated string tasks_id = 1;
}

message TaskNotify{
    string task_id = 1;
    TaskStatus task_status = 2;
}

message TaskStatusRequest {
    string task_id = 1;
}

message TasksStatusResponse {
    string task_id = 1;
    TaskStatus task_status = 2;
}

service TaskService{
    rpc CreateTask(TaskRequest) returns (TaskResponse) {}
    rpc ListTask(TaskListRequest) returns (TaskListResponse) {}
    rpc StatusTask(TaskStatusRequest) returns (TasksStatusResponse){}
}

what happen on that code?

option go_package will be result as your package grpc after .go files generated
enum is the type enum of TaskStatus will be message will be like the type struct on golang
string task_id = 1; is explain the type data of task_id is string and the number should be consistent on the field. the number is need to identify the binary serialize later. so if you want later to add new field, you must not to change the the number on the field, just add it. it can break the backward compability when deserialize later.
service TaskService is the defined of service grpc

after you coded that, lets go to folder proto and execute this command to generate the grpc code go

 protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
*.proto

and you will see the result on proto folder have 2 files
agent.pb.go -> the Go struct definitions for messages proto, It also includes methods to serialize/deserialize (marshal/unmarshal) the messages to/from binary or JSON formats.

agent_grpc.ob.go. -> contains the grpc specific code, like the server / client definitions and also list of method / services grpc

Lets do the real code

after generated the grpc code, create files client.go on folder client and fill with this code.

client.go


package client

import (
    agentsrv_proto "github.com/jufianto/state-agent/proto"
    "google.golang.org/grpc"
)

type AgentService struct {
    Key string
    agentsrv_proto.UnimplementedTaskServiceServer
}

type TaskResult struct {
    TaskID     string
    TaskResult string
    TaskStatus string
}

func NewAgentClient(key string) *AgentService {
    return &AgentService{
        Key: key,
    }
}

func (a *AgentService) RegisterGW(srvGrpc *grpc.Server) {
    agentsrv_proto.RegisterTaskServiceServer(srvGrpc, a)
}

and also code the handler.go

handler.go


func (a *AgentService) CreateTask(ctx context.Context, req *agentsrv_proto.TaskRequest) (*agentsrv_proto.TaskResponse, error) {
    fmt.Printf("got request %+v \n", req)

    return &agentsrv_proto.TaskResponse{
        TaskId:     req.TaskId,
        TaskResult: "waiting for processing",
        TaskStatus: agentsrv_proto.TaskStatus_PROCESSING,
    }, nil
}

func (a *AgentService) ListTask(ctx context.Context, req *agentsrv_proto.TaskListRequest) (*agentsrv_proto.TaskListResponse, error) {

    log.Println("list tasks", req.GetTasksId())

    return nil, fmt.Errorf("not yet implemented")

}

func (a *AgentService) StatusTask(ctx context.Context, req *agentsrv_proto.TaskStatusRequest) (*agentsrv_proto.TasksStatusResponse, error) {
    log.Println("status tasks", req.GetTaskId())

    return nil, fmt.Errorf("not yet implemented")
}

what happen on that code?
so, client.go it the base client for our primary services, it will hold the agentsrv_proto.UnimplementedTaskServiceServer interface to make sure the handler will implemented the services grpc.

the real thing gRPC is coming from this code agentsrv_proto.RegisterTaskServiceServer(srvGrpc, a) it will make the grpc server registered on this handler and can be used later as grpc services.

and for the handler.go it will impelented from grpc generated code from the rpc we defined on protofiles. on the proto files, you can see you have rpc services look like this

    rpc CreateTask(TaskRequest) returns (TaskResponse) {}
    rpc ListTask(TaskListRequest) returns (TaskListResponse) {}
    rpc StatusTask(TaskStatusRequest) returns (TasksStatusResponse){}

and all of this method grpc need to be implemented as you can see from the handler.go

Finally, lets write the main.go

main.go


package main

import (
    "fmt"
    "log"
    "net"

    "github.com/jufianto/state-agent/agent/client"

    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
)

func main() {

    srvGrpc := grpc.NewServer()

    srv := client.NewAgentClient("key123")
    srv.RegisterGW(srvGrpc)

    fmt.Println("service listening....")

    net, err := net.Listen("tcp", ":3333")
    if err != nil {
        log.Fatalf("failed to register grpc: %v", err)
    }

    reflection.Register(srvGrpc)
    srvGrpc.Serve(net)

}

srvGrpc := grpc.NewServer() will be init the grpc server, and srv.RegisterGW will be registered the handler to server grpc and finally do serve on srvGrpc.Serve(net) with port 3333

reflection.Register(srvGrpc) it just for helper to check what all the services on grpc services.

Run your services

to run your services, please do run
go run agent/main.go and it will looks like

and you need to test it by postman

you can see from the list down on postman, there have option list Create Task, ListTask, thats the use of reflection package. it will help us to check what all the method on the gRPC services.

FAQ

Q: usually on Rest API services, I see there have routing that help route the services based on the path we called. but Why I dont see on here?
A: that's the magic of grpc, basically its not based on routing but based on the method implemented. the method handler it should be same with the method we defined on the grpc generated code or can be simplified based on the proto rpc services defined.

The Github Repo for this Projects

[!NOTE]
if you have anything to ask please reach me on twitter and if you confuse with my bad writing you also can comment
and all of this explanation based my experience, so feel free to correct me if I share the miss information

twitter: https://x.com/jufiantohenri
linkedin: https://www.linkedin.com/in/jufianto/