DEV Community: koded

Designing a Collision-Resistant Deployment Naming Service

koded — Sun, 19 Jul 2026 15:46:15 +0000

This started as a random thought while solving coding problems.

Imagine you're building something like Vercel or Render.

A user deploys a project called:

portfolio

If nobody has used it before, great.

portfolio

But if someone already owns it, you need something like:

portfolio-km82x

Simple enough.

Until you start asking questions.

What if two users deploy portfolio at the exact same time?
How do you stop collisions?
How do you make the suffix human-readable?
Should it always be five characters?
How do you avoid ugly strings like 111 or aaa?
What happens when there are already two million portfolio-* deployments?

That innocent problem suddenly becomes a mix of algorithms, probability, concurrency, and system design.

This is the approach I ended up with.

The Question

The rules for a valid suffix are highly specific:

Consist only of lowercase English letters (a-z) and digits (0-9).
The first and last characters must be lowercase letters.
The suffix length must be at least 4 characters.
No more than two consecutive digits may appear (e.g., ab12 is fine, ab123 is illegal).
No three consecutive identical characters may appear (e.g., aaa or 111 are illegal).
It cannot contain reserved substrings: admin, root, api, www.

Thinking About It

My first instinct was the obvious one.

Generate a random string.

Validate it.

If it fails, generate another.

Something like:

while True:
    suffix = random_string()
    if valid(suffix):
        break

The more I thought about it, the less I liked it.

If I already know the rules ahead of time, why generate invalid strings at all?

Instead, I flipped the problem around.

Rather than validating after generation, I made the generator incapable of producing illegal candidates.

Breaking the Problem Down

Before writing any code, I tried separating responsibilities.

Instead of one giant function, the solution naturally became four small pieces.

generate_suffix()
       ↓
   build_slug()
       ↓
try_insert_slug()
       ↓
retry if collision

Each function only knows one thing.

The generator knows nothing about the database.

The database knows nothing about suffix generation.

The retry loop coordinates everything.

That separation ended up making the implementation much simpler.

Architecture

One thing I wanted to avoid was this:

if slug not in database:
    database.insert(slug)

It looks innocent.

It also breaks the moment two threads execute it simultaneously.

Instead, I moved the uniqueness check inside the database itself.

Now the application never asks:

"Does this exist?"

It simply says:

"Try inserting this."

The database either accepts it or rejects it atomically.

Implementation

The Database Layer

To handle this purely in-memory without pulling in external infrastructure, we wrap our storage in an object that manages state via a thread lock (threading.Lock).

import threading
import secrets
from typing import Set

class InMemoryDatabase:
    def __init__(self):
        self._slug_records: Set[str] = set()
        self._lock = threading.Lock()

    def try_insert_slug(self, slug: str) -> bool:
        # Why this exists:
        # We acquire a lock so only ONE thread can execute this block at a time.
        # If the slug is taken, we signal a collision immediately.
        with self._lock:
            if slug in self._slug_records:
                return False  

            self._slug_records.add(slug)
            return True

The Generator & Retry Loop

def generate_slug(db: InMemoryDatabase, requested: str) -> str:
    LETTERS = "abcdefghijklmnopqrstuvwxyz"     
    DIGITS = "1234567890"                        
    BANNED_SUBSTRINGS = ["admin", "root", "api", "www"]

    # Try to claim the exact name requested immediately.
    if db.try_insert_slug(requested):
        return requested

    def generate_candidate_suffix(retries: int) -> str:
        suffix = []

        # Adaptive length:
        # If a namespace is crowded, scaling the length up based on retries 
        # expands the search space and keeps the retry rate low.
        length = 5 + (retries // 3) 

        for i in range(length):
            allowed = list(LETTERS + DIGITS)

            # Platform rule:
            # First and last characters must always be letters.
            if i == 0 or i == length - 1:
                allowed = list(LETTERS)

            # Lookback filtering:
            # 1. If the last two are identical, block a third.
            # 2. If the last two are digits, purge ALL digits from the pool.
            if len(suffix) >= 2 and suffix[-1] == suffix[-2]:
                if suffix[-1] in allowed: 
                    allowed.remove(suffix[-1])

            if len(suffix) >= 2 and suffix[-1].isdigit() and suffix[-2].isdigit():
                allowed = [c for c in allowed if not c.isdigit()]

            suffix.append(secrets.choice(allowed))

        return "".join(suffix)

    retries = 0
    while True:
        suf = generate_candidate_suffix(retries)

        # Guard rail against global blacklisted terms
        if any(banned in suf for banned in BANNED_SUBSTRINGS):
            retries += 1
            continue

        candidate = f"{requested}-{suf}"

        # Write-intent check:
        # Try to write it directly. If another thread beat us to this specific suffix, 
        # the database returns False, and we loop cleanly to try again.
        if db.try_insert_slug(candidate):
            return candidate

        retries += 1

Why This Works

There are three ideas carrying most of the solution.

1. Generate valid candidates

Instead of generating random strings and rejecting half of them, the generator filters its character pool while building the suffix. That removes entire classes of invalid states.

2. Let storage own uniqueness

The generator never worries about collisions. It creates candidates. The storage layer decides whether they're acceptable. This keeps both components independent.

3. Retry is cheap

A collision isn't an error. It's just another iteration. As the namespace becomes more crowded, the suffix length gradually increases, expanding the search space without changing the rest of the algorithm.

Things I'd Change In Production

Move uniqueness to a real database: Replace the in-memory set with a persistent storage engine using a proper UNIQUE index constraint on the slug column.
Make banned words configurable: Pull the BANNED_SUBSTRINGS list out of hardcoded arrays into an external config or cache layer so it can be updated dynamically.
Use a Base32 alphabet: Explicitly modify the character pool to use a Base32 variations index that excludes visually confusing symbols like 1, l, 0, and O to optimize readability.
Add rate limiting: Enforce API-level rate limiting on a per-user basis to prevent brute-force naming attacks from exhausting the namespace.
Add metrics & tracing: Emit performance telemetry capturing collision rates and the number of generation cycles per request to monitor namespace saturation over time.

Complexity

Step	Complexity
Lookup	`O(1)`
Generation	`O(k)` where $k$ is suffix length
Validation	`O(k)`
Insertion	`O(1)`
Overall	Expected `O(1)`

Note: The overall time complexity is an expected $O(1)$ because our adaptive suffix length ensures that even as the database grows, the probability of multiple sequential collisions drops exponentially.

Thoughts

This was one of those problems that looked tiny until I started pulling on the thread.

It began as "append a random suffix."

A few hours later I was thinking about:

concurrency
atomic writes
adaptive search spaces
cryptographically secure randomness
human-readable identifiers

Those are my favorite kinds of problems, the ones that quietly combine algorithms with real software engineering.

If nothing else, it reminded me that some of the most interesting engineering challenges aren't hidden inside binary trees or dynamic programming problems. They're hiding behind features we use every day without thinking about them.

AI in Computing

koded — Fri, 17 Jul 2026 13:47:53 +0000

"Maybe we were never paying for intelligence. Maybe we've always been renting computation."

Yesterday, I was taking a dump while watching SpaceX's 13th test flight.

As one does.

Somewhere between watching another rocket leave Earth and seeing yet another post about Grok getting better, I found myself thinking about something completely different.

Not AI.

Not the latest model.

Not benchmarks.

Not who cooked who on X yesterday.

But... computing.

What does computing actually mean in an AI economy?

For years, computing felt invisible. I wrote some code, deployed it somewhere, and trusted that the cloud would magically do its thing. CPUs became faster, GPUs became more powerful, data centers became larger, but I never really stopped to think about what was actually happening underneath all of it.

Then AI happened.

Suddenly every prompt had a price.

Every generated image.

Every line of code.

Every research session.

Every "thinking..." animation.

Somewhere in the world, a warehouse full of GPUs wakes up just to answer a question that started with someone typing a few words into a textbox.

That's when something clicked for me.

The interesting part isn't that AI is expensive.

The interesting part is that compute has quietly become the product.

We like to say we're paying for AI.

I'm not sure we are.

I think we're paying for access to an absurd amount of computation that's been wrapped inside an intelligent interface.

The intelligence is what we see.

The compute is what we pay for.

If every token costs compute... are tokens slowly becoming a currency?

The more I thought about it, the weirder the entire industry became.

Microsoft invests in OpenAI.

Amazon pours billions into Anthropic.

Google competes with Anthropic while also investing in it.

NVIDIA sells chips to every single one of them.

They're partners.

They're competitors.

They're customers.

They're suppliers.

At the same time.

It feels less like companies fighting each other and more like one giant ecosystem where everyone is simultaneously helping and competing with everyone else.

It's honestly funny when you stop and think about it.

Everyone is connected. Everyone is competing.

What happens when everyone depends on everyone else?

I don't think we're witnessing an AI race anymore.

I think we're witnessing a compute race.

Models will continue getting better.

Interfaces will continue changing.

Benchmarks will continue being broken every few weeks.

But underneath all of that, the real question feels much simpler.

Who owns the infrastructure capable of producing intelligence at scale?

Maybe that's why countries are suddenly racing to build data centers.

Maybe that's why energy has become part of AI conversations.

Maybe that's why GPU supply chains make headlines.

The conversation isn't really about AI anymore.

It's about everything underneath AI.

As software engineers and students, I don't think our job is simply to keep learning the newest framework or whichever model released yesterday.

AI already contains an unbelievable amount of human knowledge.

Our job is different.

To build with it.

To question it.

To innovate alongside it.

Most importantly, to make sure we don't slowly outsource the parts that make us human in the first place.

Our curiosity.

Our creativity.

Our culture.

Our judgment.

Because if intelligence becomes abundant...

Those might end up being the only things that remain scarce.

I don't really have a conclusion.

I'm still trying to make sense of all of this myself.

But I keep coming back to the same question.

If computation is becoming the world's most valuable resource, what does that make software engineers?

How Does the Internet Pay?

koded — Sat, 11 Jul 2026 01:25:05 +0000

The internet got very good at moving information. It's still surprisingly bad at moving money. I think that gap is about to close, and this is the hypothesis I can't stop thinking about.

A few nights ago I got stuck on a question that felt almost too simple: what if software could just pay?

Not open a checkout page. Not redirect me to Paystack. Not wait for me to type my card number and an OTP. I mean actually pay, by itself, the same way it already sends an API request or fetches data from another server.

That question sent me down a rabbit hole, and it led me somewhere I didn't expect. Over the last thirty years, the internet became incredibly good at moving information around the world in milliseconds. It never got that good at moving money. Almost every payment still stops and waits for a human to step in.

This is an essay about what happens when that stops being true.

Payments Were Built for Humans

If you think about it, almost every payment you have ever made follows the same shape. You decide to buy something, you tap a button, you enter your card or open your banking app, you approve an OTP, and you wait for a success screen. We have done it this way for so long that it feels like the natural order of things.

The problem is that every step in that flow quietly assumes a person is present. It assumes someone is there to read a screen, tap a button, and decide whether to continue. That made complete sense, because for decades humans were the only ones buying anything on the internet.

Software does not think like that. An AI agent does not understand why it has to stop working just because a checkout page appeared. It does not care about dashboards, pricing tiers, or billing portals. It only knows it needs a service to finish the job you gave it.

Imagine asking an AI to build a report on traffic in Lagos. Halfway through, it realises it needs satellite imagery from one company, weather data from another, and map data from somewhere else. It knows exactly what it needs. But instead of continuing, it hits three pricing pages asking it to sign up, pick a plan, enter a card, and create an account. The agent is not stuck because it cannot understand the task. It is stuck because the internet still expects a human to take over.

That is when I started wondering what it would look like if payments worked the way API requests do.

Start With Something You Already Understand

Forget APIs for a second. Think about Uber.

Today, the flow looks like this:

You request a ride.
A driver accepts.
The ride ends.
You pay.

Now imagine tomorrow. You tell your assistant, "Get me to the airport." It orders the ride for you. Uber replies that the trip costs ₦8,200. Your agent approves the amount and pays. The driver shows up, you travel, and it is done. You never opened the app, and you never tapped confirm.

Or take something even more ordinary. Your fridge notices you are low on milk, so it places an order, pays for it, and a delivery shows up later that day. You did not open an app, choose a plan, or approve anything in the moment, because you already told it what it was allowed to do.

Most people do not need to understand HTTP to want that. They just recognise the story. And underneath that story sits a real technical problem: how does the software actually pay for the small pieces it uses along the way? That is where a protocol like x402 comes in.

One Answer Is x402

Somewhere in that rabbit hole, I came across x402, and the idea behind it is simpler than the name suggests.

Picture a convenience store. You pick up a bottle of water, walk to the counter, hear that it costs ₦500, pay, and leave. You did not open an account with the store or subscribe to a monthly plan just to buy one bottle. You paid for exactly what you wanted, at the moment you wanted it.

x402 tries to make the internet work the same way. Instead of signing up for an API, choosing a plan, entering a card, waiting for a webhook, and copying a key before your first request, your software simply asks for what it needs. The service replies with something like, "This request costs ₦20." Your software pays. The service confirms the payment and returns the data. Payment becomes part of the conversation instead of a separate journey you have to leave and come back from.

The trick is that x402 does this by reviving an old, unused part of the web. When a client asks for a paid resource, the server answers with an HTTP 402 "Payment Required" response and the price. The client pays, usually in a stablecoin, and retries the same request with proof of payment attached. The server verifies it and returns the resource. The whole exchange happens in a single round trip, with no account and no manual checkout.

So is x402 just a way for APIs to charge each other? In its current form, mostly yes, and that is the point. It is built for machine-to-machine payments, the tiny purchases software makes while doing its job. This is not a small experiment either. It started at Coinbase in 2025 and now sits under neutral foundation governance, with names like Visa, Mastercard, Stripe, Google, and AWS attached to it. By early 2026, a little over a year after launch, it had already processed more than 165 million transactions, at an average of around thirty cents each. Those are not human purchases. They are machines paying machines, in amounts too small for a card network to bother with.

Which brings the Uber story back into focus. When you say "get me to the airport," you experience one clean action. Underneath, the agent might be quietly buying live traffic data, route options, and pricing from several services. x402 is what lets those machine-to-machine purchases happen without an account for each one. The part where your actual fare reaches the driver still rides on more familiar rails. The interesting shift is everything happening underneath, out of sight.

Different Technologies, Same Destination

The more I read, the more I realised x402 is not happening on its own. It is one piece of a much bigger movement, and the other pieces are already here.

Account-to-Account (A2A) payments move money straight from one bank account to another, skipping the card networks entirely. Nigeria has NIP. India has UPI. Brazil has Pix. Different names, same idea: fewer steps, lower cost, faster settlement.

Agentic and conversational checkout is arriving too, and Nigeria is right in the middle of it. Paystack recently launched Paystack Index, which lets you ask an assistant like Claude or ChatGPT to buy airtime, send money through Zap, or order food on Chowdeck, and the assistant actually completes the transaction instead of just explaining how. What I find most interesting is not the conversation. It is the fine print: you set the permissions and spending limits, and the agent can only act inside them.

AI agents themselves are becoming capable enough to make real decisions on your behalf, which is what makes all of the above suddenly matter.

On the surface these look like three different projects. One is about APIs, one is about bank transfers, one is about user experience. But I do not think they are solving different problems. I think they are solving different parts of the same problem: how do we make moving money feel as natural as sending a message or making a request?

For years, the internet became brilliant at moving information. Money never caught up. Every payment still needs approval, a card, an OTP, or a switch to another app. Information evolved much faster than money did, and that gap is finally starting to close.

The next version of the internet isn't about moving more information. It's about moving value.

And I don't think the goal is simply faster payments. The best payment is not the fast one. It is the one you barely notice happened at all.

The Next Step Is Autonomous Payments

Here is where my own hypothesis starts to form. If payments keep getting simpler and more programmable, we stop asking how people pay and start asking how the internet pays.

Autonomous payments are not about replacing humans. They are about letting software handle the small decisions that do not really need us anymore. Your phone already does plenty without checking in each time:

It downloads updates overnight.
It backs up your photos.
It syncs your files across devices.
It refreshes your mail and messages.

You allowed all of that once, and now it simply happens. So why should payments be the one thing that always needs you standing there?

Imagine you are building an AI travel assistant, and you ask it to plan a trip to Kigali. Along the way it needs weather data, flight prices, hotel availability, maps, and exchange rates. Today it can find those services, but it cannot really pay for them, so everything stalls the moment a checkout page appears.

Now imagine a different version, where the agent already has permission to spend small amounts on your behalf. It pays as it goes:

₦50 for weather data
₦100 for richer flight options
₦20 for maps
₦80 for hotel availability

Then it hands you a finished travel plan, with no interruptions and no ten separate approvals. Just like your phone silently backs up your photos today, your assistant silently pays for the services it needs tomorrow. Not spending money however it likes, but spending it within rules you already agreed to. That difference is the whole thing.

The Missing Layer Isn't a Wallet. It's Trust.

At first I thought the answer was machine wallets. Give every agent a wallet, let it hold money, let it pay for whatever it needs. Simple. Except it isn't.

If you have ever left an EC2 instance running on AWS for a few days, you already know why. The problem was never that AWS let you create resources. The problem was waking up to a bill you did not expect. That is exactly why AWS gives you budgets, alerts, limits, and permissions. It does not stop you from building. It puts guard rails around what can happen.

Autonomous payments need the same thing. Not unlimited wallets, but programmable trust. You would create a wallet for your agent not by handing it your money, but by handing it rules, for example:

No more than ₦5,000 in a single day.
No single payment above ₦500 without asking me first.
Only pay for maps, weather, and travel data. Block every other category.

In this design, your agent never talks straight to a payment provider. Every payment passes through a policy engine first, which asks a few plain questions:

Is this service trusted?
Is this within today's budget?
Has the spending limit already been reached?
Does this need human approval?

If every answer checks out, the payment goes through. If not, it simply says no. The agent is not deciding how much freedom it has. You decided that before it ever spent a single naira.

This is the part most conversations skip. Everyone talks about how software can pay. Very few people talk about how software should be allowed to pay. And you can already see the serious players betting on the second question. Paystack Index shipped with spending limits on day one, not as a feature to add later. The moment software can spend your money, those limits stop being a setting and become the actual product.

The goal isn't making payments autonomous. It's making autonomous payments trustworthy.

So Where Does Blockchain Fit Into This?

You might have noticed I went this far without leaning on blockchain, and that was on purpose. I don't think blockchain is the main story here. The main story is programmable payments. Blockchain just happens to be one of the first technologies that made them possible.

Software has exchanged information over the internet for decades. One server asks another for data, and it responds. Money never worked that cleanly, because it dragged along banks, card networks, processors, and settlement windows, all built around a human making the payment. Then blockchains showed up, and for the first time software could hold a wallet, sign a transaction, and send or receive money entirely on its own.

Whether or not you like crypto, that was a real shift. It was less about inventing new money and more about making money programmable. I think a lot of us misread this during the early Web3 years, when the loud conversation was about decentralizing everything. Underneath the noise, something quieter was happening: storage, identity, and compute were all becoming programmable, and now payments are heading the same way.

The important part is that this future does not have to belong to blockchain alone. Imagine your bank exposing the same programmable capability. Your agent would not care whether the money moved over a blockchain, an instant bank transfer, or a rail nobody has built yet. It would just ask, "Can I pay for this?" and let the infrastructure sort out the rest. The future belongs to whichever technology makes moving money feel as effortless as moving information.

The Internet Is Learning to Exchange Value

When the internet went mainstream, its superpower was sharing information. You could email someone across the world in seconds, search almost anything, and build an app that talked to another app thousands of miles away. Information became effortless to move. Money did not. Even now, paying for something online still feels like briefly leaving the internet, filling a form, switching apps, approving, and waiting before you return to what you were doing.

I think that is starting to change, and not because of one protocol, one company, or one blockchain. When you zoom out, the pattern is hard to miss. A2A payments make moving money between accounts faster and cheaper. x402 makes payment a native part of a request. Agentic checkout like Paystack Index makes paying feel like a conversation. Capable AI agents tie it all together. They solve different problems, but they push toward the same future, where software can find a service, understand its price, pay for it, get the result, and keep working without waiting for anyone to click a button.

Honestly, I don't think most people will notice when it happens. Nobody thinks about TCP/IP before sending a message on WhatsApp, and one day we probably won't think about payment rails before software pays for something. It will just happen.

This is not abstract for me. I have been building an operating agent with a few friends for a hackathon, with a simple goal: give people across Africa access to digital services through something as familiar as making a phone call. As we built it, one question kept surfacing. What happens when the agent needs to pay? Not next week, not after creating an account, but right now, mid-task. That question is what started this whole rabbit hole.

Maybe the future of payments is not about making people better at paying. Maybe it is about making payments disappear, not because money disappears, but because software becomes trusted enough to handle it for us. I don't know exactly what that looks like yet. Maybe x402 becomes the standard. Maybe banks expose programmable payment APIs. Maybe someone builds something that replaces both.

What I do know is that the question has changed. For years we asked how people pay on the internet. I think the next decade is about a different one entirely.

How does the internet pay itself?

About the Author

Over the last few years I've built fintech systems at Skurel, working on fraud detection and OTP infrastructure. I won the GTCO Squad Hackathon, one of the largest in Nigeria, with a product called Recivo. I facilitated Build with Paystack, where I taught more than fifty students how to integrate Paystack and design production-ready payment flows rather than just checkout buttons. And through Koded Labs, I keep shipping products that touch payments in one way or another.

Lately my curiosity has drifted toward the layer beneath all of that. Not just building things that accept payments, but understanding how money actually moves across the internet, and what changes when software becomes trusted to move it on our behalf.

If you're building in fintech, infrastructure, or AI, or you just think a lot about where payments are headed, I'd genuinely love to talk.

I Built Beacon: An Open-Source Nervous System for AI Agents

koded — Sun, 05 Jul 2026 18:36:33 +0000

Over the past few months, AI agents have gone from being little experiments to becoming actual coworkers. They're writing code, browsing the web, answering emails, generating reports, and orchestrating workflows that would normally require entire teams. The more I thought about that future, the more one question kept bothering me.

What happens when there aren't ten AI agents? What happens when there are fifty thousand?

Everyone loves talking about what AI agents can do, but very few conversations revolve around what happens behind the scenes once they begin operating at scale. Every one of those agents continuously changes state. They start tasks, finish them, fail unexpectedly, retry operations, wait for resources, and move through dozens of transitions during their lifetime. Every transition is an event that needs to be captured, observed, and sometimes persisted forever.

That sounds simple until thousands of agents decide to do it at the exact same moment.

At that point, your application isn't just handling API requests anymore. It's trying to process an overwhelming stream of concurrent events without losing information, without destroying database performance, and without making users stare at a dashboard that updates several seconds behind reality.

That became the problem I wanted to solve.

I had recently started reading Designing Data-Intensive Applications, a book that has quickly become one of my favourite engineering books. Rather than reading it like a textbook, I wanted to approach it differently. Every chapter became a challenge to build something inspired by the ideas I had just learned.

Instead of simply reading about distributed systems, I wanted to experience them.

So I asked Claude to generate a realistic system design interview question.

It came back with this:

How do you ingest, strictly order, and visualize concurrent state transitions from 50,000 autonomous AI agents executing distributed workflows in real time, ensuring zero dropped events and sub-second dashboard updates without overwhelming your persistent audit database?

I stared at the question for a while.

Then I grabbed a pen and paper.

Before writing a single line of code, I sketched the architecture.

That habit has become one of the biggest improvements in my engineering journey. I rarely jump straight into an editor anymore because architecture forces you to think about constraints before implementation. It exposes bottlenecks early, encourages better questions, and often removes complexity before it ever reaches the codebase.

As I continued sketching, one realization became obvious.

The dashboard and the database had completely different priorities.

A live dashboard cares about speed. It wants updates almost immediately because users expect to watch agents move through their workflows in real time. A database, however, cares about durability and efficiency. It doesn't benefit from writing every single event individually if those writes can instead be grouped together without losing correctness.

Trying to satisfy both with the same processing pipeline felt like a mistake.

So I separated them.

Beacon sits between AI agents and every downstream system.

Incoming events are accepted immediately by lightweight gateway services before being published into Kafka. Rather than sending every event directly to a database, Kafka becomes the central event log that absorbs bursts of traffic while preserving ordering for each individual agent.

That ordering is surprisingly simple.

Every event is produced using the agent's identifier as the Kafka message key. Kafka guarantees ordering inside each partition, so every event belonging to the same agent always arrives in the order it was produced. No expensive sorting logic is required later because the ordering guarantee already exists inside the messaging system itself.

Sometimes the simplest decisions end up removing entire categories of complexity.

Once events enter Kafka, the pipeline splits into two completely independent consumer groups.

The first consumer exists solely for the live dashboard. Its responsibility is simple: consume new events and immediately broadcast them to connected browsers using WebSockets. Users watching the dashboard see state transitions appear almost instantly, regardless of what is happening elsewhere in the system.

The second consumer has a completely different job.

Instead of prioritizing speed, it prioritizes efficiency. Events are accumulated in memory before being written to persistent storage in batches. This dramatically reduces the number of database transactions while maintaining a complete audit history. Offsets are only committed after a successful batch write, ensuring that failures never silently discard data.

Neither consumer blocks the other.

The dashboard remains responsive even if persistence slows down, and the database continues writing efficiently even during bursts of activity.

That separation became the core architectural idea behind Beacon.

While building the project, I intentionally chose technologies that emphasized the architectural ideas rather than production complexity.

Redpanda provides a lightweight Kafka-compatible broker that is incredibly easy to run locally. SQLite keeps persistence simple while allowing the storage layer to be swapped for PostgreSQL later without changing the overall design. FastAPI made building independent services straightforward, while React handled the live dashboard that visualizes everything happening inside the system.

The result is a project that demonstrates distributed event processing without requiring an entire Kubernetes cluster to understand.

Beacon also reminded me that system design is far more enjoyable when ideas become software.

Reading about partitions, event streams, consumer groups, batching strategies, and ordering guarantees is valuable, but seeing those concepts come alive inside a running system changes how you understand them. Suddenly they stop being interview buzzwords and become practical engineering tools for solving real problems.

That has become my favourite way to learn.

Read something.

Think about it.

Build it.

Break it.

Understand it.

Beacon is completely open source because I wanted it to become more than just another portfolio project. Whether someone wants to learn distributed systems, monitor their own AI agents, experiment with Kafka, or contribute improvements, I hope the project becomes a useful starting point.

If you've ever wanted to understand how large-scale event pipelines work without reading thousands of lines of production code, I hope Beacon gives you that opportunity.

I'll continue building projects inspired by the ideas I learn, documenting the process, and sharing both the successes and the mistakes along the way.

Because at the end of the day, that's how I learn best.

⭐ GitHub: Beacon

📺 Full build video: I Built a System That Can Handle 50,000 AI Agents (Open Source)

Architecture Diagram:

How Building Antlers Changed the Way I Think About Software

koded — Sun, 05 Jul 2026 18:29:36 +0000

For a long time, most of the things I built looked similar. A user opens an application, clicks a button, a request is sent to the backend, the backend processes it, stores some data, and returns a response. Whether it was a booking system, a social platform, or another web application, the pattern was always familiar. I was focused on building products that users could interact with directly.

When I decided to start learning system design, I promised myself I wouldn't do it the way I usually learn new topics. Instead of spending weeks watching videos or reading articles before writing any code, I wanted to learn by building something that forced me to think differently. That decision eventually became Antlers.

At first, I thought I was building a real-time heatmap. Looking back now, I realize that the heatmap was probably the least interesting part of the project. What I was really building was the infrastructure required to continuously process thousands of events, transform them into something meaningful, and deliver those insights to users with almost no delay.

The original problem was inspired by something I imagined happening inside a company like Glovo or Uber Eats. Suppose the marketing or operations team wants to display a live heatmap showing where orders are currently being placed across a city. From a customer's perspective, this creates excitement and social proof by showing that the platform is active. From an operations perspective, it provides immediate visibility into where demand is increasing.

The obvious implementation would be to save every driver location or order event to the database and have the frontend periodically request the latest data. That approach works when there are only a handful of users. However, once you begin thinking about thousands of drivers sending location updates every few seconds, it becomes clear that constantly writing to the database and repeatedly querying it is an expensive way to answer a simple question: "Where is activity happening right now?"

That realization completely changed the way I approached the project.

Instead of treating the database as the center of the system, I started thinking about the movement of data itself. A driver's location is not just something that should be stored forever. It is first an event. Events arrive, they are processed, transformed into useful information, and only then do you decide what is worth storing permanently. This small change in perspective led me toward an event-driven architecture.

Rather than processing everything inside the API, incoming location updates are immediately sent to Kafka, allowing the API to remain responsive regardless of how much traffic it receives. Dedicated consumers then process those events and aggregate them into geohash buckets inside Redis. Instead of broadcasting thousands of individual GPS coordinates to connected clients, the backend only sends aggregated density information through WebSockets, allowing the frontend to reconstruct the heatmap efficiently.

One of the most interesting lessons from this architecture was understanding that not every piece of information deserves to live in a relational database. Driver locations are constantly changing. By the time one coordinate has been written to disk, the driver may already be somewhere else. Redis turned out to be a much better fit because it allows the system to maintain an in-memory representation of what the city looks like right now, rather than what it looked like several seconds ago.

As the project evolved, I started asking myself another question. If the system already knows where drivers are and how demand changes over time, why should it only describe the present? Why couldn't it make reasonable predictions about the immediate future?

My first thought was to integrate an external AI API, but the more I considered that approach, the less it made sense. Continuously sending snapshots of operational data to an external model would introduce additional latency, recurring costs, and API rate limits. More importantly, the prediction problem itself wasn't particularly complicated. I wasn't trying to generate natural language or summarize documents. I simply wanted to estimate how demand was changing over time.

Instead, I began experimenting with a lightweight regression model trained on periodic snapshots taken directly from Redis. Every few minutes, the system records the current state of activity across the city, allowing the model to gradually learn how demand evolves throughout the day. The longer the system runs, the more historical context it accumulates, all without relying on any external AI provider.

The biggest takeaway from building Antlers wasn't learning Kafka, Redis, or WebSockets individually. It was realizing that system design is much less about choosing technologies and much more about deciding where responsibility should live. Once each component has a single responsibility, ingesting events, buffering traffic, aggregating state, broadcasting updates, or making predictions, the overall system becomes much easier to reason about and extend.

Removing the Bare Minimum Limiter — Part 2

koded — Mon, 13 Apr 2026 22:20:08 +0000

Week of chaos, exams, a hackathon I almost didn't attend, and somehow, a W.

There's this thing that happens to me at hackathons.

I show up, I build, we lose. Or I don't show up, and somehow, we win. It's happened enough times that it stopped being a coincidence and started feeling like a curse. Like my physical presence was the variable that broke everything.

So when the Harvard Health Hackathon landed on the same week as my university exams; same area, same Lagos heat, I made peace with not going. I told my team I'd be around if they needed me. I wasn't planning to walk through those doors.

Then I walked through those doors.

The Last One In

I was the last participant to arrive.

My team had been there for a while. The energy was already off, deployment issues, things not connecting, the usual chaos that shows up right before a deadline. I dropped my bag and started asking questions.

The main problem: we couldn't deploy the blockchain anywhere. Our backend needed to ping it, and a free Render server couldn't handle it. We were tight on time, no budget for a quick VPS, no clean solution in sight.

I sat with it for a minute.

Then: run everything on my laptop.

Backend. Blockchain. Frontend. All of it local, on my machine, turned into a server. Tunnel only the frontend through ngrok. Print the prototype. Walk into the pitch room.

It worked.

PharmChain

The product was PharmChain: a blockchain-based pharmaceutical supply chain tracker built for the Nigerian healthcare system. Counterfeit drugs are a real, deadly problem here. PharmChain puts every drug on-chain, traceable from manufacturer to patient, unforgeable.

It was the kind of idea that makes judges lean forward.

And when my teammate stood up to pitch; he was professional. Clean slides, confident delivery, answered every question. The judges didn't just clap. They offered to put in a good word with the managing directors of companies in the space.

I was sitting in the back trying not to manifest a loss.

The Announcement

You know that specific kind of fear; where you want something badly enough that your body starts preparing for disappointment before the results are even out?

That was me. Sitting there. Running the mental math on every hackathon I'd physically attended.

They called our name.

I broke the loop.

Everything Else That Happened This Week

Because apparently one thing isn't enough:

Exams. Multiple. Same week. Still standing.

Leetcode Blind 75. I'm at 40/75 in 13 days. Doing at least 2 problems daily, mastering patterns, not just solving, understanding why the solution works. In my free time I'm watching coding interview breakdowns on YouTube and running mock interviews.

Fog of War. This started as a hackathon submission. I was literally one minute late to submit. But I'm still building it. Full sprite system, better controls, tighter game mechanics. This isn't a hackathon project anymore. This is a game I'm building until it's actually peak. Catch the vibe on X: https://x.com/coder0214h

Stackd with Koded. Week 2 with the first paying cohort. People are showing up. That means something.

5 rejection letters. They came in a batch one morning. Bending Spoons, Twilio, Remote, a couple others. It stings, I won't pretend it doesn't. But I applied, I got feedback, I improved the resume, I kept moving. That's the only response that makes sense.

VC conversations from the hackathon. The judges' interest in PharmChain opened doors I didn't expect. More on this as it develops.

The Pattern

I used to think my presence at hackathons was the problem. Ten-plus events of building and losing while sitting right there, it messes with your head.

But I think the real variable was never me being there or not. It was whether I showed up ready. Whether I had something to give when things broke.

This week, things broke. I fixed them. We won.

That's the limiter coming off, not confidence, not motivation. Just doing the work until you're the person the team calls when it matters.

More next week. Stay Cracked.

— Köded

My Last Few Months

koded — Sat, 04 Apr 2026 23:24:54 +0000

Nobody told me that doing everything at once was going to feel like this.

Exams last month. A hackathon deadline this week. A full technical lead role at Teenovatex. A bootcamp I launched from scratch. And somewhere in between all of that, I wrote a book.

This is what the last few months have actually looked like for me. Not the highlight reel. The whole thing.

I am Koded. I build things. Sometimes too many things at the same time. And somewhere in the chaos of this season I stumbled into the most practical education of my life — one that no classroom, no book, and no two hour YouTube video could have given me.

It started with a realization that hit me harder than I expected. I had been running on what I now call the bare minimum limiter. A quiet mental filter that killed high-effort ideas before they ever had a chance to breathe. Anything that felt like too much got scaled down automatically. I didn't even notice I was doing it.

When I finally saw it clearly I made a decision. April would be different. No limiter. Full throttle.

So here is what the last few months actually looked like.

I built Janus.

Janus is an AI-native execution framework I built for the Ranger Hackathon on Solana. The idea was simple but the execution was anything but — an autonomous trading bot that manages Delta-Neutral strategies on Drift Protocol while enforcing on-chain compliance through a smart contract policy engine and MPC sharded key security via the Ika Network.

What that means in plain English — most AI trading bots require full private key access, which is terrifying from a security standpoint. Janus splits the key, enforces spend limits and protocol rules on-chain, and requires an atomic compliance check before any trade executes. The AI is an operator, not an owner. It literally cannot move funds without permission from the on-chain judge.

Four layers. Python and Gemini for strategy. Drift V2 and Jupiter for trading. Solana and Anchor for enforcement. Ika Network for security. Built while I had exams. Built while I was launching a bootcamp. Built because removing the limiter meant I stopped asking myself if now was a good time.

I led at Teenovatex.

As Technical Lead I have been making architecture decisions, running developer sessions, and making sure we are building things that actually matter. The role has taught me something I didn't expect — leadership is less about knowing the most and more about creating the conditions for other people to do their best work. That lesson has shown up everywhere else in my life since.

I launched Stackd with Koded.

Four days. That is how long it took to go from idea to paying students. Flier, pricing, copy, registration flow, WhatsApp community , built in a weekend. Then we hosted a free live session at Teenovatex. Thirty plus people showed up. We had a hostess, a TX rep, structured slides, a full script, interactive polls, real conversations. We broke down every major tech track in plain English and let people ask anything.

The response was something I didn't fully anticipate. People didn't just find it useful. They felt seen by it. Because we talked about the real stuff, tutorial hell, not knowing where to start, being scared that tech is too hard, watching everyone else figure it out while you're still standing still.

We now have paying students across all six tracks. More coming.

I wrote a book.

After the session I sat down and wrote The Cracked Dev Playbook. Thirteen chapters. The entire framework we taught in the session, which track is right for you, what your first thirty days look like, how to build a resume that actually gets interviews, why YouTube tutorials are failing you, and what Stackd is here to do about all of it.

It got over 100 reads in the first few hours. From a book I wrote in one sitting. After a hackathon build. After a live session. After exams.

And here is what I actually learned from all of it. Not from reading. From doing.

Warm leads go cold in five minutes. The moment someone says they're interested is the moment to act. Waiting even an hour changes the energy completely.

Free value converts better than everything else. The free session brought in more students than every paid post combined. Give something real first. Trust does the selling for you.

People buy from people. Every conversion happened in a direct conversation. Not from a caption. Not from a flier. From me talking to a person like a human being.

Structure beats hustle. A clear offer, a clear price, and a frictionless way to register matters more than how loud you shout or how hard you grind.

Your network is infrastructure. The senior developers in my circle are now tutoring on the platform. The resources around you are almost always being underused.

And the biggest lesson of all — the bare minimum is a personality, not a strategy. Once it becomes your default you stop seeing the ceiling because you've convinced yourself the floor is enough.

I am a few months into the most real education of my life. No campus. No lecturer. No exam; well, except the actual exams I was also sitting 😂. Just real decisions with real consequences and lessons that stick because they cost something.

I don't know exactly where this goes. But I know I'm not doing the bare minimum anymore.

And that changes everything.