DEV Community: Damola Adegbite

How Would I Build For Right Now

Damola Adegbite — Wed, 27 May 2026 17:49:57 +0000

How Would I Build For Right Now

There's a woman selling food on the street. Two years in. She restocks, pays her supplier, feeds her kids, shows up tomorrow. Not rich, not struggling. Moving.

Someone tells her she needs a proper system. Inventory tracking. Demand forecasting. A loyalty programme. She looks around and the people doing well all have these things. The businesses she admires run on proper systems. So she sets it up. Spends time and money getting it right.

Six months later she's still on the street. The system is on her phone, untouched. Her margins are thinner from the setup cost. The customers she was supposed to retain with the loyalty programme don't own smartphones.

She didn't fail because she was careless. She looked at people succeeding and copied what they were doing. Those businesses had enough money to be wrong. They could try a loyalty programme, watch it fail, absorb the cost, and move on. She couldn't. Same pattern, completely different consequence. Nobody told her that part.

She also built for a version of her business she had no evidence for.

She knew what sold each day. She knew when she ran out. She knew what she made each week. That was her data. That was her use case. Everything else the forecasting, the loyalty programme, the full system was a guess she dressed up as a plan.

Your use case is defined by evidence, not aspiration. What you have data for is the only thing you are qualified to build for right now. Everything else is a guess wearing the clothes of planning.

The data is what makes the problem real. No data, no problem, no justification to build for it.

There is a version of her business where inventory tracking makes complete sense. Twenty vendors, three locations, a proper supply chain. The businesses she was copying were probably at that version or past it.

She had no data saying her business was heading there. No evidence the loyalty programme would land. No proof the forecasting would matter. Just the image of people further along than her, doing things that worked for where they were, not where she was.

The present needed to know what sold today, what to restock tomorrow, how much she made this week. A notebook solves that. She did not need a system. She needed to survive long enough to need one.

Software is the same problem.

You get a project, a deadline, a client. Before you write a line you are already making decisions about architecture, standards, what professional looks like. Most of those decisions happen on autopilot, based on what you were taught, what your peers are doing, what the successful companies are running on.

Everyone knows Netflix uses microservices. Everyone knows the big fintech companies have event-driven architectures. So a new startup gets pitched the same thing on day one, by someone who means well, pointing at companies with thousands of engineers and years of data justifying every layer of that complexity.

You have a 30-day deadline, one developer, three hundred users. Half of them are your own team testing the thing.

Those companies had enough engineering capacity to absorb getting it wrong. You do not. Same pattern, completely different consequence. And you have no data for that complexity.

This is not an argument against microservices or any pattern.

Nothing is premature if you have evidence for it. The moment you have real traffic, real bottlenecks, a team size that makes a monolith genuinely painful, the architecture that fits that data is not premature. It is the answer the evidence is pointing to.

The problem is never the pattern. It is the absence of data that justifies it.

Some things are load-bearing from day one regardless of scale. Building anything with compliance requirements, anything where a wrong number means someone's rent does not go through tests, auditing, proper error handling are not optional there. You follow those standards because the data about what failure costs is already clear. A wrong transaction is not a bug you patch quietly. It is a disaster with a paper trail.

That is the distinction. Some standards are justified by the data in front of you today. Others are borrowed from a version of the system you have no evidence for yet. The first category does not move. The second goes on the backlog.

There is an order of operations that matters.

Can this thing function today? Can it make money, deliver value, hold up under the weight it carries right now? Do you have data that tells you what today looks like?

After the present is stable, what does the evidence say about where this is going?

Most people reverse this. They architect for version three before version one has a single real user. The vendor bought a system for a business she had not built yet. The developer ships microservices to three hundred users because a company with three million users made it look like the right move.

The product dies somewhere in the gap between the version they built for and the version that showed up.

Before I start anything now, two questions.

What does the data say this needs to work today? Not at scale. Not in six months. Today, with the users that exist, the deadline that is real, the team that is here.

What does failure cost in this specific system? Is this the kind of system where a wrong number destroys someone's finances and their trust? Or is this one where a bug gets fixed in the next push and nobody lost sleep?

Those answers tell me which standards are non-negotiable today and which ones get deferred. Deferred, not ignored. Ignoring means you forgot. Deferring means you made a deliberate call with full awareness of what it will cost later.

The code is just the answers made real.

The woman is still on the street. The system is still on her phone. The people she copied are still running their bigger businesses, probably unaware she was ever watching.

Somewhere a developer is six hours into a distributed architecture for a product with three hundred users, building for a version of the problem they have no data for, wondering why the deadline feels impossible.

Same pattern. Borrowed from people who could afford to be wrong with it. Applied somewhere it was never meant to land.

I'm Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.

How Would I Build a Payment System That Doesn't Lose Money

Damola Adegbite — Wed, 27 May 2026 17:46:53 +0000

This is the first post in a series I'm calling How Would I Build. I take a real engineering problem, reason through it in plain language first, then attach the actual name for that reasoning at the end. Jargon comes last, not first.

I'll be upfront, I didn't sit down and immediately know all the answers here. A lot of this came from asking "okay but why would that break" until something clicked. That's the energy I'm going for.

Starting with this: how would you build a payment system that handles 10,000 transactions per second without losing a single one?

Two customers, one suya guy

There's a suya spot near you. One guy grilling. Two customers walk up at the same time and both want the last stick.

The suya guy has two hands. He can't serve both customers simultaneously. One of them has to wait.

Now imagine he ignores that and just gives both customers the same stick. That's your payment bug.

Two people hit withdraw on the same wallet at the exact same time. Both requests check the balance. Both see enough money. Both go through. You've just paid out twice what was in the account.

My first instinct was just — lock it. But I had to figure out what "lock it" actually meant before it made sense.

The answer is: whoever gets there first locks the wallet in the database before the second request can even read the balance. The second request waits. When the first one finishes, the second one checks the balance again and finds there's nothing left.

In Postgres that's SELECT FOR UPDATE. First transaction locks the row, second waits outside. No double spend.

That whole situation — multiple operations running at the same time and stepping on each other — is a concurrency problem. The specific bug where both read stale data before either writes is a race condition.

The suya guy gets popular. He buys a bigger grill.

Business is good now. The queue is long. The suya guy thinks: I need a bigger grill. More charcoal. Better equipment. He upgrades everything.

It helps. Orders come out faster. But the queue is still there. Because no matter how big the grill is, there's still one person running it. Customers still wait behind each other. And there's a limit to how big a grill can get anyway.

That's vertical scaling. You give the same server more power — more CPU, more RAM, faster storage. It buys you time but it doesn't solve the problem. The ceiling just moves higher.

At some point the suya guy realizes the grill isn't the problem. One location is the problem.

So he opens a second spot. Then a third. Now three customers are being served at the same time across three locations. The individual grills are smaller but the total output is way higher.

That's horizontal scaling. More machines, not a bigger machine. The limit is now cost, not hardware.

But not everything needs the main guy

The suya guy notices something. Most people walking up aren't placing new orders. They're just checking if their order is ready. Those people are slowing down the main grill.

So he puts a separate person to handle "is my order ready" questions. That person has a copy of the order list and handles all status checks. The main guy now only deals with new orders.

Read traffic stops choking write performance.

That's read replicas. The main database handles writes. Copies of it handle reads.

But here's where I got confused for a bit. Replicas don't fix everything. If 10,000 new orders are coming in per second, the main grill still has a ceiling on how many it can process. Adding more status-check people doesn't change that.

To scale new orders, you need more main grills. Not copies — actual separate locations taking orders. Customers 1 to 2,000 go to location one. 2,000 to 4,000 go to location two. New orders are now spread across multiple spots.

That's sharding.

What if someone at spot one wants to pay for a friend at spot three

Someone at spot one wants to cover their friend's order at spot three. The suya guy at spot one collects the money. Before he can radio spot three to release the order, his phone dies. Spot three never gets the message. The money is gone and the friend got no suya.

My instinct was to get both spots to agree before anything moves. Spot one holds the money, spot three holds the order, and only when both confirm does anything proceed. That works but it's slow. And if the person coordinating between them disappears mid-process, both spots are frozen waiting for a signal that never comes.

The simpler approach is to not wait for both at the same time. Spot one takes the money and writes down "I took this, spot three owes a release." If spot three never confirms, spot one automatically reverses the charge and refunds the customer. No coordination needed upfront. Each spot handles its own piece and knows exactly what to undo if something breaks.

That pattern is called a SAGA. Failure recovery for distributed operations. Each step has a compensating action ready before anything runs.

Multiple spots, but who tells customers where to go

You've opened five suya spots. A new customer walks up. They see five spots and have no idea which one has the shortest queue. They just stand there confused.

So you put someone at the entrance whose only job is to look at all five spots and point each new customer to the next free one. The customer doesn't think about it. They just get directed.

That's a load balancer. It sits in front of your servers and distributes incoming traffic so no single server carries everything. Nginx handles this well.

But now the person at the entrance is a single point of failure. They go down, everyone is lost.

So you have a backup person standing right next to them. If the first one goes down, the backup steps in automatically. That switch is called failover. Running both is a high availability setup.

Rate limiting sits on top of this. You cap how many orders one person can place per minute. It won't solve legitimate volume but it stops bad actors from making the problem worse.

Something goes wrong and you have no idea which spot caused it

At 10,000 transactions per second, a failed transaction could have broken at the entrance, the order taker, the payment handler, the records person, or the notification sender. Logs scattered across twenty servers.

I genuinely didn't think about this until I asked myself — if something breaks at this scale, where do I even start looking?

The fix is to give every order a unique ticket number the moment it enters the system, then write that ticket number into every record that order touches across every spot.

When something breaks, you search for that ticket number and see the full journey of that order in one place. Every step, every spot, in order.

That ticket number is called a correlation ID. Following a request across services using it is called distributed tracing.

Tools like Datadog or the ELK stack pull logs from all your servers into one searchable place. Elasticsearch stores the logs. Kibana is the dashboard you use to search them.

What the full picture looks like

A request comes in. The load balancer directs it to one of several servers, with a standby ready if the active one dies. Rate limiting filters abuse. The server processes the transaction with pessimistic locking to prevent race conditions. Reads hit replicas, writes hit the primary. Sharding distributes write load across multiple database nodes. Cross-spot transactions use SAGA so failures don't leave money in limbo. Every step logs with a correlation ID that flows into a centralized system where any transaction can be traced end to end in seconds.

That's a payment system that doesn't lose money.

I'm Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.

How Would I Build a Payment System That Doesn't Lose Money

Damola Adegbite — Thu, 21 May 2026 23:05:11 +0000

How Would I Build a Payment System That Doesn't Lose Money

This is the first post in a series called How Would I Build. I take a real engineering problem, reason through it in plain language, then name the concept at the end. Jargon comes last.

I didn't sit down knowing all of this. Most of it came from asking "okay but why would that break" until something clicked.

Starting here: how do you build a payment system that handles 10,000 transactions per second without losing a single one?

Two customers, one suya guy

There's a suya spot near you. One guy grilling. Two customers walk up at the same time and both want the last stick.

He can't serve both at once. One of them has to wait.

Now imagine he ignores that and gives both customers the same stick. That's your payment bug.

Two people hit withdraw on the same wallet at the exact same time. Both requests check the balance. Both see enough money. Both go through. You've paid out twice what was in the account.

My first instinct was: lock it. But I had to understand what "lock it" meant before it made any sense.

Whoever gets there first locks the wallet in the database before the second request can even read the balance. The second request waits. When the first finishes, the second checks again and finds nothing left.

In Postgres that's SELECT FOR UPDATE. First transaction locks the row, second waits outside. No double spend.

Multiple operations running at the same time and stepping on each other is a concurrency problem. The specific bug where both reads happen before either write is a race condition. The lock pattern is pessimistic locking.

The suya guy gets popular. He buys a bigger grill.

The queue is long now. So he upgrades everything. Better grill, more charcoal, faster setup.

It helps. But the queue comes back. Because no matter how big the grill is, one person is still running it. There's a ceiling.

That's vertical scaling. More power to the same machine. It buys time, nothing more.

At some point the grill isn't the problem. One location is.

So he opens a second spot. Then a third. Three customers served simultaneously across three locations. Smaller grills, higher total output.

That's horizontal scaling. More machines, not a bigger one.

Not everything needs the main guy

Most people walking up aren't placing new orders. They're checking if their order is ready. Those people are slowing down the grill.

So he puts a separate person on "is my order ready" questions. That person has a copy of the order list and handles all status checks. The main guy handles new orders only.

Read traffic stops choking write performance.

That's read replicas. The main database handles writes. Copies handle reads.

But replicas don't fix everything. If 10,000 new orders are coming in per second, the main grill still has a ceiling. To scale writes, you need more main grills — actual separate locations taking orders, not copies. Customers 1 to 2,000 go to location one. 2,000 to 4,000 go to location two.

That's sharding.

What if someone at spot one wants to pay for a friend at spot three

Spot one collects the money. Before the suya guy can radio spot three to release the order, his phone dies. Spot three never gets the message. The money is gone and the friend got no suya.

Getting both spots to agree before anything moves works, but it's slow. And if the person coordinating disappears mid-process, both spots freeze waiting for a signal that never comes.

The better approach: don't wait for both at once. Spot one takes the money and writes down "I took this, spot three owes a release." If spot three never confirms, spot one reverses the charge. Each step knows exactly what to undo if something breaks. No upfront coordination.

That pattern is a SAGA. Every step has a compensating action ready before anything runs. Stripe uses this for cross-service money movement.

Multiple spots, but who directs customers

Five suya spots now. A new customer walks up and has no idea which one has the shortest queue.

So someone stands at the entrance. Their only job is to look at all five spots and point each new customer to the next free one.

That's a load balancer. It sits in front of your servers and distributes incoming traffic. Nginx handles this well.

That person at the entrance is now a single point of failure. So a backup stands right next to them. First one goes down, the backup steps in. That switch is failover. Running both is a high availability setup.

Rate limiting sits on top of this. One customer can only place so many orders per minute. It won't solve legitimate volume, but it stops bad actors from making things worse.

Something breaks and you don't know where

The fix: stamp every transaction with a unique ID the moment it enters the system, something like txn-8f3a2c, and write that ID into every log it touches. When something breaks, you search that one ID and see the full journey in one place.

That ID is a correlation ID. Following a request across services using it is distributed tracing. Tools like Datadog or the ELK stack pull all those logs into one searchable place.

The full picture

A request comes in. The load balancer sends it to one of several servers, with a standby ready if the active one dies. Rate limiting filters abuse. The server runs SELECT FOR UPDATE to lock the row. Reads hit replicas, writes hit the primary. Sharding splits write load across multiple database nodes. Cross-node transactions use SAGAs so failures don't leave money in limbo. Every step logs a correlation ID that flows into a centralised system where any transaction can be traced end to end.

The suya guy who once stood alone at one grill now runs five locations, a backup at every entrance, a separate person on status checks, and a ledger that knows exactly what to reverse when something goes wrong.

That's a payment system that doesn't lose money.

I'm Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.

I built a tool that shows developers what their backend costs the planet

Damola Adegbite — Sat, 18 Apr 2026 19:44:55 +0000

I built a tool that shows developers what their backend costs the planet

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

carbondebt is a cloud emissions dashboard for backend developers. Put in your cloud provider, region, and monthly compute hours. It calculates your CO2e footprint, breaks it down by service, and uses Google Gemini to return ranked actions with estimated carbon savings per month.

No account. No setup. Results in under ten seconds.

Developers track technical debt across quarters. We argue about it in code review, carry it into sprints. But there is another kind of debt building up in every infrastructure decision, one that never shows up in your AWS bill. Carbon debt works the same way. It compounds quietly and stays invisible until someone surfaces it. This tool surfaces it.

Demo

Live: carbondebt-client.vercel.app

Open the app, select AWS, set the region to us-east-1, leave compute hours at 720. Then switch to eu-north-1. Stockholm's grid is 76% cleaner than Virginia's. That difference is a decision most developers have never been asked to make.

Code

dax-side / carbondebt

carbondebt

carbondebt is a cloud emissions dashboard for developers Enter your workload numbers, then get a monthly footprint estimate and a ranked action list.

Live demo: carbondebt-client.vercel.app

What you get

Total monthly CO2e
Grid intensity for the selected region
Emissions split by service (compute, database, storage, network, lambda)
Best lower-carbon region inside the same cloud provider
Gemini suggestions sorted by estimated monthly savings

How carbon is calculated

The backend uses scope 2 location-based emissions from local region intensity data. Intensity values come from Ember Global Electricity Review 2025.

Formula:

CO2e (kg) = kWh * grid_intensity (gCO2e/kWh) / 1000

Source file for region values: server/src/data/regions.ts

Stack

Frontend: React, Vite, TypeScript, Tailwind CSS
Backend: Node.js, Express, TypeScript
Validation: Zod
AI: Google Gemini
Logging: Morgan + Winston

API

GET /api/health

Returns service status.

POST /api/carbon

Request body:

{
  "provider": "aws"
  "region": "us-east-1",
  "computeHours": 720

…

View on GitHub

How I Built It

The frontend is React with TypeScript and Tailwind. The backend is Node.js and Express. No database. Every request is self-contained.

Carbon calculations run locally on the server using regional grid intensity data from the Ember Global Electricity Review 2025 dataset. No third-party emissions API. The numbers are transparent and traceable to the source.

One thing I added that changed how the data reads: the "equivalent to X km driven" metric. Saying a workload produces 125 kg CO2e per month is accurate but abstract. Converting it to kilometres driven makes the number land for people who have never thought about this before.

Gemini integration: After the carbon report is calculated, it goes to Gemini which returns 3 to 5 ranked infrastructure suggestions specific to the submitted workload. Not generic advice. Things like "switch to Graviton3 instances" or "stop non-production servers outside business hours" with an estimated kg saving attached to each one. The formula gives you the number. Gemini tells you what to do with it.

Prize Categories

Best Use of Google Gemini

Gemini takes the carbon report and turns it into something a developer can act on today. Each suggestion is ranked by estimated monthly CO2e saving and tied to the actual workload submitted. If Gemini is unavailable, the carbon report still renders. The suggestions are an addition, not a dependency.

GitNotion — GitHub to Notion sync with AI reports

Damola Adegbite — Mon, 16 Mar 2026 11:09:57 +0000

This is a submission for the Notion MCP Challenge

What I Built

GitNotion is an MCP server that pulls GitHub activity into Notion and uses Gemini to write reports on top of it. Point it at any repo and it syncs issues, PRs, and commits into structured Notion databases, then generates weekly summaries, release notes, and contributor breakdowns. All free APIs, ships via npx.

Eight MCP tools, accessible from Claude Desktop, Copilot, or any MCP client:

Tool	What it does
`setup_workspace`	Creates 4 Notion databases under a parent page
`sync_issues`	Pulls GitHub issues into Notion
`sync_pull_requests`	Pulls PRs into Notion
`sync_commits`	Logs recent commits to Notion
`generate_summary`	Sends last week of activity to Gemini, writes a summary page
`generate_release_notes`	Generates release notes from merged PRs and commits
`get_contributor_insights`	Per-contributor stats with an AI written report
`full_sync`	Runs everything above in sequence

Re-running any sync tool updates existing entries. No duplicates.

Video Demo

Show us the code

Repo: https://github.com/dax-side/gitnotion

npm: npx -y gitnotion

How I Used Notion MCP

GitNotion embeds the official @notionhq/notion-mcp-server as a dependency and uses it as the write layer for all page operations. The architecture:

AI Agent (Claude, Copilot, etc.)
    ↓ MCP protocol
GitNotion MCP Server  ← custom server
    ├── GitHub API (read repo data)
    ├── Gemini API (generate reports)
    └── Official Notion MCP Server  ← all page/block writes go here
         └── Notion API

When a sync or AI tool runs, GitNotion spawns the official Notion MCP server as a subprocess, connects to it as an MCP client, and routes all page create, update, and block append calls through it using API-post-page, API-patch-page, and API-patch-block-children. Database creation goes through the Notion SDK directly since the official server doesn't expose that endpoint.

Gemini returns markdown. Notion doesn't accept markdown — it wants structured block objects for every heading, list item, table row, and inline annotation. The converter handles all of that, then the blocks get sent to the official MCP server via API-patch-block-children in chunks of 100. Chunking is needed because passing large content in a single call times out. The pattern is: create the page first with no children, then append in batches.

To use it, add this to your MCP client config:

{
  "mcpServers": {
    "gitnotion": {
      "command": "npx",
      "args": ["-y", "gitnotion"],
      "env": {
        "GITHUB_TOKEN": "...",
        "GITHUB_REPO": "owner/repo",
        "NOTION_TOKEN": "...",
        "NOTION_PARENT_PAGE_ID": "...",
        "GEMINI_API_KEY": "..."
      }
    }
  }
}

Four free things needed: GitHub token, Notion integration token (connected to your page via ••• > Connections), Gemini API key, and the Notion parent page ID from the URL. Ask your MCP client to run setup_workspace, then pass the returned database IDs to full_sync.