DEV Community: c0d3l0v3r

The System Has Awakened: Turn Your Coding Journey Into a Solo Leveling RPG ⚔️

c0d3l0v3r — Sun, 12 Jul 2026 15:24:40 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

This weekend, I built a gamified, AI-driven learning platform that treats mastering software engineering like clearing an S-Rank dungeon.

When i watched the Anime Solo leveling i was inspired by the thing in the Anime called "System". basically, you act as a "Player" receiving instructions from the "System." You choose a career path (e.g., Full Stack Web Developer, Rust Systems Engineer), and the AI generates a dynamic curriculum. The System acts as your Quest Master, giving you hands-on coding tasks. You submit your code, the AI grades it, and if you pass, you level up your engineering stats. If you fail, you trigger a brutal Penalty Zone task to force your growth.
Simple... Isn't it ? It took a good amount of time to configure the supabase and the Google AI and make it really usable + deploy it just over the weekend

Demo

🎮 Live Demo:

Here is the Demo, if you are evaluator or just want to see how the application works here is the video

Because the app requires Google OAuth to register your "Player Profile," here is a look at what happens inside the System once you awaken:

Status of the Player

Code

c0d3l0v3r-HeHe / sl-app

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

Next.js Documentation - learn about Next.js features and API.
Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more…

View on GitHub

How I Built It

I tried to keep the architecture simple and as it is a prototype application, i use the NextJS with the Supabase for the authentication with Google OAuth Setup.

Frontend & Framework: Next.js 16 (App Router) paired with React 19. The UI relies on TailwindCSS v4 to build a highly customized, immersive "System" skin featuring dark modes, monospace formatting, pulsing neon accents, and responsive layout structures.
Database & Auth: Supabase PostgreSQL houses the entire player state. It tracks persistent user profiles, historical quest completion records, active roadmaps, and independent skill trees (Frontend, Backend, Low-level, System Programming, DevOps).
AI Integration: I integrated the @google/genai SDK using the gemini-3.1-flash-lite model to act as the core game engine.

Interesting Technical Decisions:
Instead of hardcoding the learning paths, I used Gemini to dynamically generate the roadmaps based on user input, outputting strict JSON schemas so the frontend could map the data without parsing errors.

When a player submits code, it is sent via a system prompt to the Gemini API alongside the strict rules of the quest. The model acts as an isolated sandbox evaluator, returning a Pass/Fail boolean, a score out of 100, and actionable feedback directly into the UI.

Prize Categories

I am submitting this project for Best Use of Google AI.

The entire "Quest Master" and "Automated Code Evaluator" features are powered entirely by the Google Gemini API (gemini-3.1-flash-lite). The AI not only generates the curriculum but dynamically scores the player's code to determine if they earn EXP or trigger a Penalty task.

This was all about the Submission , below this line, the rest of the post starts that contains the user journey and other things like technical details of the project.That makes a post instead of jsut a submission...

💡 Inspiration: The Passion Behind the Project

Stop the Weakness.....

This weekend, I wanted to capture the ultimate feeling of obsession, progression, and self-improvement by bringing the mechanics of the iconic anime Solo Leveling into the real world.

In the story, the protagonist receives access to a mysterious System that grants:

Daily quests
Immediate stat upgrades
Brutal penalty zones
Continuous progression

allowing him to evolve from the Weakest Hunter of All Mankind into humanity's strongest.

This application follows the same idea and uses AI to give the paths for the developers to select from and practical quests, although it is just an AI and don't put your carrer on the line. But, when i saw the system in the Anime i thought it would be great for the most of us lazy engineers.

It bridges the gap between raw passion for building software and the structured discipline required to become a stronger software engineer.

🎮 The Player(User) Journey

Image Generated by ChatGPT given the user flow diagram using lucidchart

🛠️ Technical Deep Dive & Architecture

The application is built on a modern web stack designed to feel responsive, immersive, and game-like.

Frontend

Next.js 16 (App Router)
React 19
TailwindCSS v4

The interface recreates the aesthetic of the Solo Leveling System with:

Terminal-inspired UI
Dark theme
Neon blue accents
Responsive layouts
Animated status panels

Database & Authentication

The database stores:

Player Profiles
Active Roadmaps
Quest History
EXP
Levels
Individual Skill Trees
Achievement Progress

Authentication is handled through Google OAuth.

State Management

Players can freely multiclass.

Switching learning paths instantly loads independent:

Stats
EXP
Roadmaps
Progress

without affecting other classes.

🤖 Best Use of Google AI

The heart of the application is the @google/genai SDK using:

gemini-3.1-flash-lite is used for the generation of the tasks and the evaluation of the code,
without the safe mode,
without any high load,
because i cann't afford.

HeHe ( Internal Rapper Sleeps ) 🤘🎤🎶🔥

Here are the following detials about the AI and what does it do :

1. Dynamic Curriculum Engine

Instead of hardcoding learning paths, Gemini creates personalized progression trees based on:

User goals
Current experience
Desired specialization

Every roadmap is unique (Hopefully, you cann't Trust AI. can you).
Lazy me

2. Intelligent Code Evaluation

Submitted code is evaluated using Gemini with strict system prompts.

Example response:

{
  "pass": true,
  "score": 88,
  "feedback": "Clean implementation of the sorting algorithm. However, you can optimize the spatial complexity by avoiding the slice allocation on line 14.",
  "statAllocated": "Low-level Programming",
  "expAwarded": 25
}

Players immediately receive:

Pass / Fail
Numerical score
Personalized feedback
EXP rewards
Skill allocation

without requiring a human reviewer.

🔮 Future Roadmap

Currently, it is a good idea i would say but we can further increase it by adding communnities and Collaborative Events.

👥 The Shadow Army (Collaborative Raids)

Multi-player boss battles where developers collaborate to:

Build open-source projects
Complete architectural challenges
Defeat timed raid bosses

Teamwork becomes progression.

⚡ Instant Dungeon ( Similar to CodinGames)

A dedicated arena for:

Timed coding challenges
Code golf
Algorithm battles
Rare rewards
Exclusive profile titles

Designed for quick daily practice sessions.

🎯 Vision

Learning software engineering shouldn't feel like completing another checklist.

It should feel like stepping into a dungeon, accepting increasingly difficult quests, overcoming failures, and watching your character and your real-world skills—grow stronger every single day.

The System has awakened.

Will you answer the call?

Into-The-OS: Process and Scheduling

c0d3l0v3r — Sun, 12 Jul 2026 00:17:55 +0000

Hello and welcome to Part 3 of the Into-the-OS series! This part aims to cover Chapter 6 of OSTEP. We will primarily dive into processes, Limited Direct Execution (LDE) alongside its problems and solutions (plus a few of my own opinions), and the dynamic between user space and kernel space 😉.

Direct Execution -> Limited Direct Execution

Okay, let's think about it this way: what is the absolute fastest way to run a process on the CPU? Simple: just run the process.

No fluff, just raw, direct performance. Hence the name Direct Execution. Simple enough, right? (Well, at least until I/O calls start staring at us from the background.)

So where is the problem?

Imagine you own a factory with a machine and a single worker. When an order comes in, the worker is responsible for doing everything needed to get the job done. Their tasks might include:

Fetching things from the market
Running the machine
Writing the report to you and telling how much time might be needed

So, can you guess the problem?

When the worker is out at the market, the machine sits idle. Assuming we are incredibly greedy for efficiency, we don't want that machine to stop for anything other than a mandatory cooldown.

So here is what will happen:

The time the worker takes to fetch materials from the market is wasted — the machine sits idle.

This, my friend, is exactly the problem with I/O calls. If a process waits for I/O, the CPU wastes precious cycles sitting idle.

Now, to offload this work, you hire a manager to oversee the worker. But this introduces a second problem: what if the worker tries to access confidential information, or attempts to take factory resources home?

We need two things to fix this:

Control: We don't want to give the resources to the worker (we are greedy, remember 🤑).
Performance: We also want to make as much profit as we can.

That's where the word LIMITED comes into play. We give control to the Manager (the OS) to maintain security, while offloading the responsibility of performance management.

Limited Direct Execution means the process still executes directly on the CPU, but we limit its ability to interact with the machine's hardware and resources.

A Practical Example

If you are familiar and can distinguish the difference between a Synchronous program and an Asynchronous program, you understand me, don't you?

There are various concepts we can pull out of this, like:

Synchronous and Asynchronous Programming
Decoupling in System Design (this includes various methods)

But all of these are based on one single concept: separating execution from fetching/uploading.

Addressing the Performance

Okay, now if sitting idle is the problem — what if, when this worker gets to work, we send another worker to the market to get materials? This would fix the issue, and the machine would not be idle.

Here's a program that shows this in action:

This is accessible in the Into-the-OS GitHub repository:

c0d3l0v3r-HeHe / Into-the-OS

A hands-on exploration of Operating System fundamentals. This repo contains the C/C++ code, calculations, and practical experiments accompanying the "Into the OS" deep-dive series.

Into-the-OS

View on GitHub

These functions run as threads. Quick refresher if you're not familiar with threads: a thread isn't a process — it's a lightweight unit of execution within a process, and all the threads belonging to a process share that process's address space. Think of them as the individual workers for one process. In our hypothetical Factory (the process), we have 2 threads (workers) doing the work.

A quick caveat: this demo uses threads purely to illustrate the general idea — "don't let the CPU sit idle." It's programmer-level concurrency happening inside a single process. The actual mechanism OSTEP is describing in this chapter is different: the OS scheduler context-switching between separate, independent processes when one of them blocks on I/O. Threads are a great visual for the underlying problem, just don't read this code as "this is literally how the OS scheduler works."

As you can see in the code, as soon as the first worker goes to the market, the 2nd worker starts working on the machine. (Code is partially generated using AI.)

Addressing the Control

Computers enforce this by splitting execution into two modes:

Kernel Mode: The privileged mode (the Manager). It can execute all instructions and access all resources.
User Mode: The unprivileged mode (the Worker). It executes a restricted subset of instructions.

If any worker steps into the wrong room, it's the OS's responsibility to fire that worker — or the OS gets fired.

Unfortunately, we can't demonstrate this mode-switching in code the way we did with the threads example above — kernel/user mode transitions happen below the level our program can observe, so we can only walk through it conceptually here.

To execute the process, the CPU has to be handed over to it. So how does the manager get control back?

Earlier versions of operating systems relied on the phrase "TRUST THE PROCESS." Not very controlling, are they?

Earlier OSes typically used cooperative policies: it was the programmer's responsibility to hand control back to the OS after a certain amount of time. And when a developer asked, "what if I don't?" — the OS was practically silent. The answer was: you need to restart your machine….

To fix this, we moved to a timer-based approach. There's a timer running in hardware from the moment the computer boots, and after a certain threshold, a timer interrupt fires, handing control back to the OS. The OS then decides whether to keep running the current process or swap in another one.

How do we execute an I/O call?

Now, we want the CPU to know exactly what a worker (process) can and can't access, so it doesn't touch something it shouldn't. So how are these privileged instructions executed by the CPU? Can't we just tell the CPU directly — "Hey CPU, please read or open this file"?

No — because the process doesn't have the right to open the file. It's the OS's job to check whether the worker has that right. So what actually happens when we call open?

What Happens?

When we call open() in our program, we're not calling the syscall directly — we're calling a wrapper function (provided by libc) around it. What that wrapper does is save some information into a few registers:

So when we call open(args), each argument gets saved into a register, and then a special instruction called syscall is executed.

That instruction is what hands control to the OS to actually execute the I/O. But how does the OS know which syscall to run?

See the number next to open — that 2? That doesn't identify which syscall to run; it actually refers to Section 2 of the Linux manual pages, the section dedicated entirely to System Calls.

When a program wants to open a file, it places a specific syscall number into a register (like rax on 64-bit architecture) and executes a trap instruction (like syscall or int 0x80). This switches the CPU into kernel mode and triggers the kernel's main system call handler. The OS then reads that number and uses it as an index into the System Call Table — a list, set up by the OS, containing the memory addresses of every kernel function (like sys_open). When the syscall instruction runs, the system saves the current register values onto the program's kernel stack and switches to kernel mode, where it decides whether to keep running the same process or perform a context switch (swapping out the registers and stack of the running process for those of the next scheduled process).

Here are the images that show the earlier and later control mechanisms:

Credits : The two images above are from OSTEP Book.

We've now covered how the OS handles Control and tries to optimize for Performance, and we've seen how it juggles between processes. But how does it actually decide which process runs next?

I'd planned to go further, but I think this is already pushing past the 10-minute read that's the whole point of this format — so I'll pick this up next time. See ya!!!!!!!

— c0d3l0v3r

Into the OS - Part 1: The Magic of Virtualization

c0d3l0v3r — Mon, 06 Jul 2026 06:27:28 +0000

Hey, Welcome to the article one of the series “Into-the-OS”. First, i thought we should think about the process(instructions that runs on the computer).

What is a Process ?

The set of instructions that runs on a computer or machine is called a process in the terms of Operating systems. Let’s take a code

Code is available in the github repository for the Series of Article : https://github.com/c0d3l0v3r-HeHe/Into-the-OS

Now, is this a Process ?

It might shock you , No it is not. It is not a process until we really run the object file created. Let’s figure out the files created by the command

gcc -o process process.c --save-temps

Files created by running the command above ( Compilation with — save-temps

process.i:

This is a pre-compiled file that contains the added implementations from the stdio.h file as shown in the main process.c file

process.s:
This is the assembly file that contains the instructions in RISC-V or other architectures. Here is the demo of the above:

Scary. Isn’t it ?

process.o:

It is the object file that we can run.

So, nothing fancy ?

objdump -d -s process > objDump.txt

by doing this you get another scary file objDump.txt

Now, let’s dig into the structure for some time.

Image showing the objdump -d -s for the process.o

Sections

See the things like Contents of section .dynsym, .gnu.hash, etc. These are the sections stored in a structure i will talk about later and you will be suprised.. Hehe.

Image showing .text and .rosection

We see .rodata section we see our “Hello World !!”

Let’s move to the execution. Apparently when the Program Runs it starts with the <_start> not <main> 😲:

Start of the progam

Lines showing the loading of the main in the rip and then running the __lib_start_main using the location of the main function

Rest of the instructions above and below are for security, holding argc and argv and other stuff which we might not need so we will skip it for now. But, if you are interested, you can GPT it 😉

Here we push the rbp inside the stack and store the value of the earlier stack pointer to the rbp.

Then we use lea (Load Effective Address) to calculate the location of our string.

The math: 0x1158 + 0x0EAC = 0x2004.

This 2004 is the exact address of our string "Hello World !!" living in the .rodata section. All these statements do is set up the plumbing:

**1151**: Calculate the address of the string and load it into %rax.
**1158**: Move that address from %rax into %rdi (the first argument register for any function in Linux).
**115b**: Move 0 to %eax (telling printf we aren't using floating-point vector registers).
**1160**: Call the printf stub.

If we look closely at that printf call, it does a jmp to *0x2f76(%rip).

More math: 0x105a + 0x2f76 = 0x3FD0.

This location (3FD0 in the Global Offset Table) will eventually point to the real printf implementation in your system's C library when the program actually runs. For now, because we are just looking at a static file, the real address isn't there yet!

What did we learn?

After getting a little drifted in the assembly code, let’s zoom back out and look at the structure. What exactly did we just see in this file?

Sections: distinct blocks of memory (.rodata, .plt, .got) that store specific information and data needed for the program to function.
Executable Code: The .text section, holding the raw assembly instructions for _start, main, and the PLT stubs that will eventually run on the CPU.
A whole lot of hex codes…

But wait. Here is the most important question of this entire article: Did we ever actually run the program?

No, we didn’t. We just inspected a static .o object file sitting dead on our hard drive.

So… where did all those memory addresses (1060, 2004, 3FD0) come from if the program isn't even loaded in RAM yet?

Revelation: The Illusion of Memory

This is the core magic of the Operating System.

The addresses you see inside the objdump are not real physical RAM addresses. They are virtual addresses. The executable file we compiled is nothing more than a static blueprint (an ELF file).

When you finally type ./process and hit enter, the Operating System steps in. It creates a completely isolated, private Address Space for this specific execution. It reads our blueprint, copies the .text and .rodata sections into your actual physical RAM, and then lies to the program—making it think it owns a perfect, continuous block of memory starting from those exact virtual addresses we saw in the dump.

A program is just a dead file on a disk. A Process is the active, breathing instance of that program, wrapped in a beautiful illusion of private memory orchestrated by the OS.

One more important thing to note is if i run all these 3 programs together, they should technically crash because all of their main addresses at the same point. Right?

But, they will not. Because they are just virtual addresses and the OS gives the illusion of the infinite memory. OS will give different physical memory locaiton to each one of the program that we would run.

Let’s map what we just saw in our objdump directly to this X-ray:

1. The Code & Data (The Static Stuff)

These sit at the very bottom, in the lowest memory addresses.

Remember our main function sitting at address 1149? That is loaded right into the Code (.text) block.
Remember our "Hello World !!" string sitting at address 2004? That gets loaded into the Data block right above it. Because the OS reads these directly from our ELF file on the disk, their sizes are fixed. They never change while the program is running.

2. The Stack (The Missing Piece)

If the code and data are static, how does a program actually do things dynamically? Look back at the very first instruction inside our main function: 114d: push %rbp 114e: mov %rsp,%rbp

This is the code interacting with the Stack! The Stack lives at the very top of the Address Space (the highest memory addresses). Every time you call a function, the OS pushes a new “frame” onto the stack to hold its local variables. When the function finishes (ret), the frame is popped off. The Stack actively grows downward as your program runs deeper into function calls.

3. The Heap

Right below the stack is the Heap. If you’ve ever used malloc() in C or new in C++, this is where that memory comes from. While the Stack grows downward, the Heap grows upward. (And yes, if you write a terrible infinite loop that allocates too much memory, the Heap and the Stack will eventually crash into each other, blowing up your program with a Stack Overflow or Out of Memory error. Scary, isn't it?)

Conclusion: The Brain of the Process (The PCB)

We’ve seen the memory, the assembly instructions, and the grand illusion of the Address Space. But how does the Operating System actually keep track of all this?

If the Address Space is the physical house the process lives in, the OS needs a master ledger to keep track of who owns which house, what they are doing, and what they own. In OS terms, this data structure is called the Process Control Block (PCB) (or Process Descriptor).

Every time you execute ./process, the OS doesn't just hand out virtual memory. It creates a massive C-structure deep inside the OS kernel to track everything about this specific running instance. What exactly does it store?

Process State: Is the program actively running on the CPU? Is it blocked waiting for you to type something on the keyboard? Is it terminated?
Process ID (PID): The unique integer identifier (like 4092) you see when you run commands like htop or ps in your terminal.
CPU Register State: This is the most crucial part. When the OS temporarily kicks this process off the CPU to let another program run, it saves the exact, freeze-framed values of %rax, %rsp, %rip, and all the other registers right here in the PCB. When the process gets the CPU back, the OS restores these values, and the program resumes as if it never stopped.
I/O Status Information: A list of all open files, network sockets, and connected devices the process is actively using.

A process is vastly more than just compiled code. It is an intricate, highly managed data structure maintained by the invisible engine of the Operating System kernel.

Hopefully, this deep dive gives you a clear picture of what a process truly is under the hood. We stripped away the abstraction, dumped the raw binaries, and exposed the Virtual Memory illusion that makes modern software possible.

Next up, we are going to see this PCB in action. If every process thinks it owns the CPU forever, how does the OS secretly pause them, swap their registers, and run 100 programs at once without any of them noticing?

Image showing the task struct on https://elixir.bootlin.com/linux/v7.1.1/source/include/linux/sched.h#L820

While that massive task_struct is the official way the Linux kernel tracks a process, it contains hundreds of fields we don't need to worry about right now. Moving forward in this series, we are going to stick to the classic, simplified textbook model we just built: Stack, Heap, Data, and Code. As an engineer, this is the core mental framework you will actually need.

See you in Part 2 for the math and magic of CPU Scheduling!

The Introduction

c0d3l0v3r — Sat, 27 Jun 2026 09:48:30 +0000

Operating system, a thing that everybody uses but no one talks about.

While reading Operating Systems: Three Easy Pieces (OSTEP), my background in C and C++ fueled a growing fascination with memory allocation, virtualization, scheduling, and the intricate mechanics of operating systems. This would be a series of article, the number i am not sure, it will be the amount of content that someone might comfortably read in a 10 min Article.

Keeping each piece to a solid 10-minute read is the perfect sweet spot for a developer to read over a cup of coffee. It gives you enough runway to explain a core concept, show the math, and link a practical C/C++ experiment without making their eyes glaze over.

Why this Article ? We are often warned against “reinventing the wheel.” However, I firmly believe that building and optimizing modern software is impossible without a fundamental grasp of virtualization, memory allocation, and concurrency.

Consider Docker: it functions almost entirely on OS-level virtualization features like Namespaces, cgroups, and isolated filesystems. Similarly, the highly optimized Memory Manager in PostgreSQL only works because it leverages the robust memory management systems already written into the OS kernel.

This article aims to bring the core concepts of OSTEP to life through practical experimentation. By accompanying the theory with an open-source repository, my goal is to provide a clear, interactive learning experience that demystifies operating systems.

I am not an operating system guru or a Principal Engineer with years of experience, but I hope to become one someday (assuming AI doesn’t replace me first… HeHe). What I can do is dive in, explore, and try to understand these concepts by actually building things. Because of that, my goal here is to present the findings and experiments I explore rather than giving strong opinions — I’ll leave the comment section for those! Any support, feedback, or contributions from the community will be incredibly valuable to me.

Who is this Article For ?

Anyone curious about low-level system design and how things actually work under the hood.
Peers and developers looking for a practical, hands-on refresher on core operating system concepts.
People who hate dry theory and just want to build things practically (though fair warning: we are going to dive into some essential calculations and theory notes to make the practical stuff actually work, bro…).

The Fundamentals

The Operating system as written in OSTEP and i also agree, can be learned with the help of understanding 3 fundamental concepts that forms the backbone of any application today.

Virtualization :

The ability of the operating system to give a process the illusion of infinite, private resources.

Let’s break it down with an analogy. Consider yourself a wealthy investor, and I am your property manager. On paper, I sold you a massive 100-acre farm. In your mind, you own that entire 100 acres all to yourself.

In reality, I only manage 50 physical acres, and I’m secretly juggling leases for several other investors on that exact same land. But here is the trick: you never inspect the entire 100 acres at the exact same time. Whenever you want to visit a specific acre, I scramble behind the scenes, clear out whatever else was there, and set up your stuff before you walk through the gate.

To you, the illusion is perfect — you have a massive, private 100-acre estate. Meanwhile, I (the OS) am sweating under the hood, dynamically swapping things around to make a 50-acre reality work for everyone.
Persistence :

The ability of the system to permanently retain data once it has been committed. Imagine how frustrating your life would be if you had to set up your mobile phone from scratch every single day because your contacts and settings wouldn’t save. Without persistence, everything a program does vanishes the moment the power cord is pulled. The OS handles the massive responsibility of mapping volatile, short-term memory to permanent, physical storage (like SSDs and hard drives) so your data survives.
Concurrency :

The ability of the system to handle multiple tasks or run processes in parallel. While virtualization creates a tidy, isolated world for a single process, modern applications rely on multi-threading, which introduces total chaos. The OS has to manage this concurrency with strict rules to prevent disasters :

- Mutual Exclusion: Ensuring that when one process or thread is modifying shared data (like a bank balance), no other thread can touch it at the same time.

- Determinism & Isolation: Ensuring that regardless of the chaotic order in which the OS schedules different threads, the final result of the program remains correct, predictable, and exact every single time.

Wrapping Up

Hopefully, this introduction gives you a clear picture of what this series is all about. This first piece was all about laying the foundation and mapping out the technical road ahead. Because each of these core pillars contains a massive amount of depth, math, and practical nuance, I will be separating them into their own distinct, dedicated articles moving forward.

Next up, we are diving straight into Part 1: The Art of Time Sharing, where we will peel back the layers on CPU virtualization, understand how the OS pulls off seamless context switching, and dive into the math behind different scheduling policies.

Thanks for reading, and I’ll see you in the next one… bro!

I Doubled My Servers and Wrecked My Availability

c0d3l0v3r — Sat, 27 Jun 2026 09:42:41 +0000

“Reliability is the most important feature of any system.” — Bill Gates

Why does your bank never show the wrong balance, but your favorite app sometimes takes a few seconds to update? Why do some systems feel fast but crash under load, while others feel slower but never fail?

Performance answers: “How fast is the system right now?”
Scalability answers: “What happens when demand increases?”

These questions point to a fundamental tension in system design: performance vs scalability.

A system can improve performance metrics like throughput and latency, yet fail to scale under load. This article demonstrates exactly that.

In this article, we’ll explore this trade-off through a simple analogy, and then connect it to real-world systems using measurable metrics like latency, throughput, and error rate.

The Burger Shop Analogy

Imagine a small burger shop run by a single worker, let’s call them A.

Let’s assume the following things:

Burgers are prepared automatically by machines, so A only handles taking and serving orders.
Finished burgers are placed in a shared box, from which A picks them up and delivers them to customers.

We intentionally ignore preparation time and assume burgers are instantly ready. This allows us to focus purely on how requests are handled, rather than how they are produced.

The Single Worker System

In this setup, a single worker handles all incoming requests.

When you enter the shop, you join a single queue and wait your turn before placing an order. Every request is processed sequentially (one at a time).

A few key observations:

Single queue, sequential processing

With only one line, every customer must wait for those ahead of them. This results in higher waiting time, which translates to high latency and low throughput.
No contention

Since only one request is handled at a time, there is no competition for shared resources. The system operates without conflicts or synchronization issues.
Efficient resource usage

Resources are used strictly on demand. Each burger is prepared only when needed, with no excess consumption or overhead.

What does this imply?

High latency → Each request experiences delay due to queuing
Low throughput → Only one request is processed at any given time
No contention → No conflicts between concurrent operations

Despite its limitations, this system is remarkably stable.

There are no race conditions, no lost work, and no unexpected failures. Every request is handled in a predictable and controlled manner.

Slow, but predictable.

Scaling the System

So far, the limitation has been clear: a single worker handling all requests.

To improve this, we introduce more machines. Instead of relying on a single machine, worker A can now distribute incoming orders across multiple machines.

Let’s examine what changes:

Parallel processing

With multiple machines available, several orders can be handled simultaneously. This increases the number of requests processed per unit time, leading to higher throughput and reduced latency.
Decision overhead (routing)

Worker A must now decide which machine should handle each request. This introduces a small coordination overhead — similar to how a load balancer (e.g., Nginx) routes requests in real systems.

For simplicity, we will ignore this overhead in our analysis.

What happens to the metrics?

Multiple orders can be processed simultaneously.
Waiting time decreases
Throughput increases

This approach is known as horizontal scaling, increasing system capacity by adding more resources rather than making a single component more powerful.

The Hidden Problem

So far, scaling seems like a clear improvement.

But consider the shared burger box , the place where all machines deposit finished burgers.

What happens if multiple machines try to place burgers into the box at the same time?

This introduces two critical failure scenarios:

Lost Work

One burger makes it into the box, but another falls to the ground.

That burger is wasted, and the customer never receives their order.

In system terms, this is a failed request.
System Blockage

Both burgers get stuck at the entrance of the box, blocking it completely.

Now no further burgers can be placed.

In system terms, this resembles contention or resource locking, where the system slows down or stops entirely.

What Changed ?

By introducing multiple machines, we improved performance:

Higher throughput, lower latency

Multiple burgers can now be prepared simultaneously. This increases throughput and reduces waiting time for customers, improving overall performance.
Increased coordination and state management

With two machines handling requests, worker A must decide where each order goes. Both machines can process requests, so their state must be tracked and logs must be maintained. This introduces coordination overhead.
Inefficiency due to lost work

Some burgers may fall to the ground before reaching the box. These orders are wasted, and the customer never receives their burger. In system terms, this represents failed or lost requests.
Unpredictable latency

Consider a customer waiting for an order that never arrives. If they leave after 30 seconds, that request now has very high latency. Even if other customers are served quickly, overall latency becomes inconsistent and harder to predict.This is the core trade-off.

In system terms, we have introduced:

Contention for shared resources
Increased system complexity
Possibility of failure

The Core Trade-off

This is the fundamental trade-off in system design.

Some customers are served faster, but others may never get their order.

Performance

Performance refers to how effectively a system executes tasks within a given time frame. It is typically evaluated in terms of speed, responsiveness, and how efficiently system resources are utilized under load.

To understand and measure performance, we rely on a few key metrics:

Latency

Latency is the time it takes for a system to respond to a request.

In simpler terms, it measures how long a user has to wait after initiating an action.

Throughput

Throughput represents the number of requests or transactions a system can handle per unit of time.

It reflects the system’s capacity to process workload at scale.

Resource Utilization

Resource utilization measures how much of the system’s resources, such as CPU, memory, and network bandwidth are consumed while handling requests.

Efficient systems aim to maximize output while minimizing unnecessary resource consumption.

Efficiency

Efficiency describes how well a system converts resources into useful work.

A highly efficient system achieves high throughput and low latency while using minimal resources.

Scalability

Scalability refers to a system’s ability to handle increasing load by proportionally utilizing additional resources, while maintaining acceptable performance.

In other words, a scalable system does not degrade significantly as the number of users or requests grows, it adapts by efficiently distributing the workload.

To evaluate scalability, we observe how key performance metrics behave under increasing load, including:

Latency under load
Throughput under load
Resource utilization
Error rates (failures, timeouts)
Number of concurrent users supported

A system is considered scalable if these metrics remain stable or degrade gracefully as demand increases.

Availability

Availability is the measure of a system’s ability to respond to requests within an acceptable time frame.

A system is considered available if it is operational and capable of returning responses, even under load. High availability systems are designed to minimize downtime and ensure that users can reliably access the service.

“A system can be highly performant but not scalable. for example, a single powerful server may respond quickly, but fail when user load increases.”

The Monolith vs. The Load-Balanced Fleet (A vs 2A’s)

To move beyond theory, we need to observe how a system behaves when pushed to its absolute limits. To test the relationship between compute scaling, database bottlenecks, and overall availability, an A/B load test was constructed.

The code for the experiments can be found in attached github repository:

c0d3l0v3r-HeHe / performance-vs-scalability-experiment

performance-vs-scalability-experiment

View on GitHub

Assumptions

Before running the load test, the architecture was built on three core hypotheses:

Linear Scalability: Doubling the compute resources (adding a second application server) will linearly increase the system’s maximum throughput.
Testing Default Database Limits: We hypothesized that the default connection pool of a single MongoDB instance would be sufficient to handle the concurrent load of doubled compute resources.
The Load Balancer Penalty is Negligible: The network hop introduced by routing traffic through a reverse proxy will be outweighed by the massive gains in request processing speed.

Setup Methodology

The experiment was conducted locally using Docker to containerize and isolate the environments. The testing tool, k6, was configured to inject a stepped load simulating aggressive traffic spikes: starting at 100 concurrent virtual users and ramping up to 2,000 users over an 80-second window.

The workload itself was a mixed Read/Write operation. Every request forced the application to write a new document to the database and immediately read a document back, simulating a standard transactional endpoint.

We tested three distinct architectures:

Architecture A (The Baseline): A single Node.js/Express application connected directly to a standalone MongoDB instance. This represents a traditional, unscaled monolith.
Architecture 2A (The Distributed Compute): Two identical Node.js/Express applications sitting behind an Nginx load balancer. Nginx utilized a round-robin strategy to distribute incoming k6 traffic across both nodes. Crucially, both application nodes were wired to the exact same single MongoDB instance.

const express = require("express");
const mongoose = require("mongoose");
const os = require("os");

const app = express();


mongoose.connect("mongodb://mongo:27017/testdb", {
  maxPoolSize: 50,
});

const TestSchema = new mongoose.Schema({
  value: Number,
});

const Test = mongoose.model("Test", TestSchema);

app.get("/", async (req, res) => {
  const start = Date.now();

  try {
    await Test.create({ value: Math.random() });
    await Test.findOne();

    const latency = Date.now() - start;

    res.json({
      latency,
      server: os.hostname(), 
    });
  } catch (err) {
    res.status(500).json({ error: "DB error" });
  }
});

app.listen(3000, () => console.log(`Server running on ${os.hostname()}`));

Results

The k6 load test yielded drastically different saturation points for the two architectures.

These reports are present as the .html files in the github respository.

Architecture A (Single Node Baseline):

The latency trade-off. With a single Node.js event loop acting as a natural throttle, the p95 latency sat at ~796ms. The system was relatively slow under heavy load, but perfectly stable.

Baseline throughput. The single-node architecture safely processed a total of 176,584 requests, hitting a hard bottleneck at roughly 2,193 requests per second.

100% Availability. Because the compute layer could not overwhelm the database connection pool, every single read/write transaction was successfully completed without a single dropped request.

Total Requests Processed: 176,584
Throughput: 2,193 requests/second
Latency (p95): ~796 ms
Failure Rate: 0.00% (100% Success)

Architecture 2A (Distributed Compute):

The smoking gun. While the p95 latency for successful requests actually dropped to ~492ms, the maximum latency spiked to an unusable 36 seconds. The explicit HTTP 500 errors confirm the single MongoDB instance was pushed into connection exhaustion.

The illusion of scale. Adding a load balancer and a second application node successfully pushed our throughput to over 3,600 requests per second, processing 350,261 total requests.

The breaking point. Scaling the compute layer while leaving the data layer untouched resulted in a massive 26.5% failure rate, actively degrading the system’s availability.

Total Requests Processed: 350,261
Throughput: 3,638 requests/second
Latency (p95): ~492 ms (for successful requests)
Failure Rate: 26.57% (93,069 failed requests, including explicit HTTP 500 database errors and massive timeouts spiking up to 36 seconds).

Discussion

The experimental data explicitly demonstrates the systemic risks of isolated horizontal scaling. While adding compute resources improved specific performance metrics, it fundamentally compromised system reliability, proving that scaling a single tier does not equate to scaling the system as a whole.

1. The Shifting Bottleneck and Resource Exhaustion The baseline load test (Architecture A) established a clear system ceiling: a single Node.js instance capped throughput at 2,193 requests per second with a p95 latency of ~796ms. Crucially, the failure rate was 0.00%. In this configuration, the compute layer acted as a strict upstream bottleneck. Because a single server could not process requests fast enough to overwhelm the database’s connection pool (configured to a maximum of 50 connections), the database was naturally shielded from resource exhaustion. The system was relatively slow under peak load, but highly stable.

By introducing a load balancer and a second application node (Architecture 2A), the compute-layer bottleneck was removed. The system accepted more concurrent traffic, driving throughput up by roughly 65% (to 3,638 req/sec). However, because both nodes funneled this doubled traffic into the single, unscaled MongoDB instance, the bottleneck immediately shifted to the data layer. The sudden influx of concurrent requests exhausted the database connection pool, leading to connection lockups and explicit HTTP 500 errors.

2. The False Positive of “Improved” Performance A superficial reading of Architecture 2A’s metrics might suggest a performance win: the p95 latency for successful requests actually dropped by ~38% (from 796ms down to 492ms), and total processed requests nearly doubled.

However, a rigorous analysis reveals this “scale” is an illusion. The data shows a catastrophic failure rate of 26.57% (93,069 failed requests). The reduction in p95 latency for successful requests is effectively a survivorship bias metric; it only accounts for the requests that managed to secure a database connection. Meanwhile, the maximum latency for blocked requests spiked to an unusable 36 seconds. The experiment proves that forcing high throughput at the compute layer without matching capacity at the data layer destroys system availability.

3. The Inadequacy of Isolated Scaling The results strictly invalidate the hypothesis that doubling compute resources linearly increases maximum throughput safely. Instead, it proves that architectural scaling must be holistic.

When Architecture 2A pushed the database beyond its concurrency limits, the system did not degrade gracefully — it fractured, dropping more than a quarter of all user requests.

Conclusion

The data validates a core principle of distributed systems:

throughput and availability are often inversely correlated when shared resources are unscaled. Architecture A was unscalable but highly available (100% success). Architecture 2A was highly performant for a subset of users but critically unavailable for the rest (26.57% failure).

To successfully scale this system beyond the 2,193 req/sec ceiling of Architecture A without incurring the 26% failure penalty of Architecture 2A, the architecture must evolve to protect the database. Based strictly on these failure modes, future iterations must either synchronously scale the data layer (e.g., database sharding/replicas to handle the higher connection volume) or implement an asynchronous buffer (e.g., a message queue) to decouple the request ingestion rate from the database write rate.

Acknowledgements & References

The experiments and conclusions drawn in this article were directly informed by studying foundational distributed systems literature. Translating these concepts from theory into a live, containerized k6 experiment was made possible by the following resources:

Performance, Scalability & Throughput

MIT 6.004: Performance Measures (YouTube): Provided the classic “laundry analogy” illustrating why pipelining improves overall throughput but not individual request latency.
Performance vs. Scalability (Prof. Beekums): Clarified the boundaries between making a single server faster versus designing an architecture to handle increased load.
A Word on Scalability (Werner Vogels): Foundational principles from Amazon’s CTO on building systems that scale gracefully.
Latency vs Throughput (CS.fyi) & Understanding Latency vs Throughput (Cadence): Core definitions and metrics for measuring system speed and capacity.

The CAP Theorem & Consistency Patterns

CAP Theorem Revisited (Robert Greiner) & A Plain English Introduction to CAP (ksat.me): Explained the core mathematical trade-off: why our partitioned, load-balanced system had to sacrifice availability when tied to a single database.
Consistency Patterns (CS.fyi): Detailed breakdowns of Weak, Eventual, and Strong Consistency, which directly inspired the Redis asynchronous queue experiment.

High Availability, Failover & Database Replication

Availability in Distributed Systems (GKCS — YouTube): A practical war story detailing a real-world database migration, downtime management, and understanding the “9s of availability.”
Scalability, Availability & Stability Patterns (SlideShare): A comprehensive visual overview of architectural patterns.
High Availability System Design Basics (DesignGurus) & System Design Availability Patterns (Dev.to): Practical guides on identifying and removing single points of failure.
Active-Passive vs Active-Active Failover (Serverion): The blueprint used for configuring our Nginx load balancer to distribute compute traffic.
Introduction to Database Replication (EnjoyAlgorithms): A deep dive into separating read/write workloads and scaling the data tier.

What Would You Change First About My Developer Portfolio?

c0d3l0v3r — Tue, 02 Jun 2026 03:39:16 +0000

I've been working on improving my developer portfolio and would appreciate feedback from other engineers and developers.

Portfolio: https://portfolio-one-rust-77.vercel.app/

Note: The portfolio is best viewed on a laptop or desktop, as some sections include interactive elements that are easier to explore on a larger screen.

Some specific questions I have:

What was your first impression after opening the site?
Is the navigation intuitive?
Are the projects presented clearly?
Does anything feel confusing, unnecessary, or distracting?
If you had 5 minutes to improve this portfolio, what would you change first?

A bit about me:

Computer Science student
Interested in backend engineering and distributed systems
Building projects involving PostgreSQL, Redis, Kafka, Docker, and observability tooling
Currently looking for internships and software engineering opportunities

I'm looking for honest feedback, including criticism. If something doesn't work, I'd rather hear it now than during an interview process.

Even if you only have one suggestion, I'd love to hear it.

Thanks in advance to anyone who takes the time to review it.

From a Simple Auth Service to a Distributed Authentication Platform with Kafka, Debezium, and Observability

c0d3l0v3r — Tue, 02 Jun 2026 03:15:27 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built a Distributed Authentication System as a long-term learning project to explore real-world backend and distributed systems concepts through a familiar use case: user authentication.

The project started as a simple authentication service with signup and login functionality. Over time, it evolved into a distributed architecture that incorporates event-driven communication, change data capture (CDC), observability, horizontal scaling, and performance testing.

The current system consists of:

PostgreSQL as the primary source of truth for user credentials
Redis for refresh token storage and session management
Kafka as the event streaming platform
Debezium for Change Data Capture (CDC) from PostgreSQL
MongoDB for materialized user profile documents
Nginx for load balancing across multiple service instances
Prometheus and Grafana for monitoring and observability
k6 for load testing and performance analysis

When a user signs up, the authentication service writes user data to PostgreSQL. Debezium captures the database change and publishes it to Kafka. A separate profile service consumes the event and creates a corresponding profile document in MongoDB. This allows services to communicate asynchronously while keeping the architecture loosely coupled.

Beyond implementing features, the main goal of this project was to understand the trade-offs involved in building distributed systems. Throughout development I conducted load-testing experiments, measured replication lag, analyzed bottlenecks, and documented the architectural decisions that shaped the system.

This project has become my personal distributed systems playground where I can experiment with new ideas, evaluate design decisions, and learn how real systems behave under load.

Demo

GitHub Repository

Repository:
https://github.com/c0d3l0v3r-HeHe/distributed-auth-system

Signup Flow

Login Flow

The repository contains additional architecture diagrams, performance experiments, load-testing results, observability metrics, and detailed documentation covering the design decisions and trade-offs explored throughout the project.

Rather than reproducing all of those results here, I've kept this submission focused on the project's journey and evolution. If you're interested in the deeper technical details, bottleneck analysis, replication lag measurements, scaling experiments, or observability setup, you'll find them documented in the repository.

The Comeback Story

This project was not originally intended to be a standalone distributed authentication platform.

In May, I started building it as the authentication backend for a larger job portal project. The initial goal was fairly straightforward: implement signup, login, token management, and the supporting infrastructure needed for user authentication.

After building the core authentication service and setting up the initial infrastructure, I shifted my focus to other work and the project was left unfinished. While the foundation existed, many of the ideas I wanted to explore—distributed systems patterns, observability, scalability, and performance analysis—were still missing.

A few weeks later, I came across the GitHub Finish-Up-A-Thon Challenge and decided to revisit the project instead of letting it remain another abandoned repository.

Rather than simply cleaning up old code, I used the opportunity to significantly expand the project and turn it into a distributed systems playground.

During the revival, I:

Added Redis-based refresh token management
Implemented a CDC pipeline using PostgreSQL, Debezium, and Kafka
Added a dedicated profile service backed by MongoDB
Introduced Prometheus metrics and Grafana dashboards
Added k6 load-testing infrastructure
Scaled the authentication service horizontally behind Nginx
Conducted multiple performance experiments and documented the results
Created architecture diagrams and expanded the project documentation

One of the most valuable outcomes of revisiting the project was discovering bottlenecks that only became visible under load. While scaling the authentication service improved CPU utilization, load testing revealed that MongoDB and the CDC pipeline became the primary bottlenecks. Investigating these trade-offs taught me far more than simply building the original authentication service.

By the end of the challenge, the project had evolved from an unfinished backend component into a fully documented distributed authentication system that I can continue using to explore distributed systems concepts, scalability patterns, and performance engineering.

My Experience with GitHub Copilot

GitHub Copilot acted as an implementation and exploration partner throughout the revival of this project.

For many components, I first designed the architecture and wrote the interfaces, function signatures, and high-level implementation plan. I then used Copilot to generate boilerplate code, suggest implementations, and accelerate repetitive development tasks.

Copilot was particularly useful for:

Generating service scaffolding and repetitive CRUD logic
Assisting with Docker Compose configuration
Helping configure Prometheus metrics collection
Suggesting Kafka consumer and producer implementations
Writing integration and infrastructure tests
Explaining configuration options for Debezium and Kafka Connect
Speeding up refactoring and cleanup work

One workflow I found especially effective was defining the architecture and API contracts myself, leaving implementation placeholders, and then using Copilot to generate an initial implementation. This allowed me to focus more on system design decisions and less on repetitive coding.

I also used Copilot while setting up and validating the distributed architecture. It helped me troubleshoot configuration issues, understand service interactions, and quickly iterate on infrastructure changes during development.

The biggest benefit wasn't code generation itself—it was the ability to move from an idea to an experiment much faster. Since this project is intended as a distributed systems learning playground, that rapid feedback loop allowed me to spend more time investigating architectural trade-offs, performance bottlenecks, and scalability challenges.

Feedback Welcome

This project started as a learning exercise and has evolved into my personal distributed systems playground.

If you're an experienced backend or distributed systems engineer and happen to read this submission, I'd genuinely appreciate any feedback on the architecture, design decisions, bottlenecks, or trade-offs discussed throughout the project.

Some areas I'm currently thinking about include:

Improving the CDC pipeline under higher load
Reducing replication lag and read amplification
Better approaches to profile materialization
Scaling strategies beyond the current setup
Observability improvements and production-readiness considerations

Constructive criticism, alternative approaches, and architecture suggestions are all welcome. One of the main goals of this project is to learn from engineers who have solved these problems in real systems.