In 2023, a Lagos fintech lost ₦4.3 million in a single night.

Not to fraud.
Not to a hack.
To a database decision, Tunde and Emeka made 18 months earlier over jollof rice and a laptop.

Here’s exactly what happened.

NB:
Purely educational, no real event. Tunde was the backend engineer.

Emeka was the CTO.

They were building a wallet-based payment platform for market traders in Lagos.

Small team.
Big vision.
6 weeks to ship an MVP.

Being a "backend engineer" is not a skill.
It's a department.

Moniepoint posted roles, struggled to find qualified Nigerians, and Nigerians on the internet showed their displeasure.

But still, nobody touched the actual problem.

This thread will make some of you uncomfortable.

That's fine.

It's only a problem for people who don't read with an open mind. First, the Moniepoint story.

They’re one of the most technically serious fintechs operating in Nigeria.

Payments infrastructure.
Real-time settlement.
High-volume transaction processing.
They rolled out job applications, and the narrative that surfaced was:
“Nigerians applied, Nigerians weren’t picked.”

But that’s not the full picture.

Building an auth system?
You need to be extra careful cos that thing is literally the front door to your entire application.
So implement the following

1. Rate limit your auth endpoints properly.
If you don’t, people will comfortably sit somewhere and spam login/register/reset password requests all day.
Doing that helps reduce brute force attempts, abuse and unnecessary load on your infrastructure.

Implement throttling too.
Especially on failed login attempts.
That one helps slow attackers down heavily instead of allowing unlimited guessing attempts per second. Add account lock mechanisms after suspicious activities.
For example too many failed logins, multiple OTP failures or unusual password reset attempts.

Even if temporary, it helps stop automated attacks from continuously hammering an account.

Visa has an offline chip protocol.

M-Pesa works without internet.

Modern fintech wallets process payments with zero connectivity.

They're all building variations of the same architecture.

Here's how offline payment systems are actually built. Most engineers think offline payments are just:

"Save locally, sync later."

That assumption breaks fast in production.

Offline payments are a distributed systems problem.

cryptography.
local state.
conflict resolution.
fraud prevention.
reconciliation.
all without a central authority online.

Pelumi’s startup processed ₦2.4 billion in transactions on a Friday payday.
Her servers crashed at 1:47 pm.
The painful reason: everything was synchronous.

This thread covers:
→ Synchronous vs asynchronous architecture
→ What a message queue actually is
→ Producers, consumers, and workers
→ Job retries and why they matter
→ Dead letter queues
→ The fan-out pattern
→ Idempotency in queue systems
→ Backpressure and why queues act as buffers
→ When to use queues and when not to

Read carefully. By the end, you’ll understand why every serious backend eventually adds a queue layer.

If this helps you think differently about system design, retweet and bookmark it for later reference. Meet Pelumi.
Founder and CTO of Remitly, a Nigerian remittance platform letting diaspora send money home directly to mobile wallets and bank accounts.

40,000 active users, growing 20% month-on-month.
Backend: NestJS. Database: PostgreSQL. Hosting: AWS.

On the surface, everything looks fine.
Until payday, Friday hits.

Tunde built a database in 3 hours and was proud of himself.

Two weeks later, the same database was giving him update anomalies, duplicate data, and queries that made no sense.

The problem wasn’t his code. It was his schema.

A thread on Database Normalization, bookmark for later reference and retweet First, understand what normalization actually solves.

When your data isn’t normalized, three things break.

Insert anomaly: You can’t add data without unrelated data.

Update anomaly: Changing one thing means changing it in 50 places.

Delete anomaly: Deleting a row wipes out data you still need.

Tunde had all three and didn’t even know it.

A Nigerian fintech founder raised $2M, built a slick app, onboarded 40,000 users.

Then CBN, NDPC, and FCCPC came knocking at the same time.

He had no licence. no DPO. no KYC tier structure. no breach policy.

The company didn’t survive 2024.

Here’s every rule you must know before you build: First, understand this:
Nigeria has no single fintech regulator.

You answer to CBN, NDPC, SEC, FCCPC, NCC, NAICOM, CAC, and FIRS, sometimes all at once, depending on what your product touches.

Most founders only know CBN.
That’s the first mistake.

The database that gaslights your users.
No errors, no alerts, no 500s.
Just a system that quietly lies to the people using it.

Retweet, bookmark then Let’s read. Wunmi just updated her profile name on a fintech app.
She clicked save, got a success toast, and refreshed the page.
Her old name was still there.
She refreshed again, still old.
She called support. Support checked the database. The new name was there.
Nobody could explain what Wunmi saw.

A Nigerian fintech startup raised $3.2M, spent 14 months building a “bulletproof” payment platform, and launched with 40k users in week one.

Investors were celebrating.

Then in one weekend… everything collapsed.

Here’s the security blind spot that destroyed them, and the system design lessons every backend engineer in 2026 must understand. Week one looked perfect.

Transactions flowing, dashboards stable, users happy.

Then support tickets exploded:

“Someone drained my wallet.”
“My balance shows -₦2.8M.”
“Unauthorized transfers at 3 am”
They thought it was a bug.
It wasn’t.

Do you understand what it means to say a distributed system in system design?

In plain, simple terms, a distributed system, as the name implies, is not just one server. It is multiple machines working together as a single system.

Let me use GTBank as a very relatable example.

You do not have just one server sitting in Lagos.
There are servers in Lagos, Abuja, and possibly even outside Nigeria.

When you check your balance or send money, your request can hit any of these servers.

They coordinate, sync data, and respond as one unified system.

That is a distributed system.

Seems interesting, right? Yes, it is.

But have you ever asked questions like:
“What happens when there is a network issue?”

That is where CAP theorem comes into play.

Let’s continue 👇🏿 Now the real problem starts when network issues happen.

Welcome to CAP theorem:

Consistency: everyone sees the same data

Availability: the system always responds

Partition Tolerance: the system survives network failure

In a distributed system, network issues are not “if”, they are “when”.
Because here in Nigeria, someday, sometime, it will definitely happen.

So when a partition, which is a network failure, happens, you must choose:

Consistency or Availability.

Not both.

Every time your bank transfer fails in Nigeria, there’s a high chance it has nothing to do with your bank.

It failed because of one system.

One piece of infrastructure that every bank, fintech, and POS terminal depends on at the same time.

It’s called NIBSS.

And most engineers building Nigerian fintech don’t fully understand what it actually does NIBSS = Nigeria Inter-Bank Settlement System.

Founded in 1993 by the CBN and commercial banks.

Simple way to think about it:

If Tunde (GTBank) sends money to Emeka (Access Bank), those banks don’t talk directly.

They both talk to NIBSS.

NIBSS is the translator, validator, and settlement engine behind every inter-bank transfer.

Without it, banks are isolated systems.

The “We’re Building for Nigerians” Lie
Let’s read.

A Nigerian startup raises $2M. The press release says “built for Nigerians, by Nigerians.”

The app requires 4G to load the dashboard. It crashes on a Tecno Spark. It times out during payment.

Meanwhile, the founders are demoing it on a MacBook Pro in a co-working space with fibre internet.

Let’s talk about this. There are two versions of “building for Nigeria.”

The first is the pitch deck version. Inclusive language, local characters in UI illustrations, naira signs everywhere, and a founder speaking Yoruba in a TechCabal interview.

The second is what actually gets shipped.

They are rarely the same product.

So, out of boredom, I decided to break down something I built recently

not a tutorial, not a flex
Just me explaining how I approached authentication in a real system.

NB: this is not a fictional thread
This is a real system I built, just written as a thread

Read till the end
bookmark it, you’ll need it sooner or later
And if it helps, do me a favour and repost before you dive in.
The architectural diagram is at the end of the thread
Make sure you save that too What I built had real consequences if anything went wrong.

So I couldn’t afford to treat auth as just email and password

I had to think in systems
layers, fallbacks, failure handling, and attack resistance

There’s something we don’t really talk about enough.

Nigeria is connected to some of the most powerful undersea cables ever built:
MainOne, WACS, ACE, Glo-1.
Billions of dollars of infrastructure sitting right off our coastline.

Yet most of my mutuals and I are still buying 1GB for ₦1,000, and it’s finishing in 2 hours.

Something is just so deeply wrong, and most people don’t even know where to point the finger. It’s very easy to assume the problem is the cables, like maybe there isn’t enough international bandwidth coming in.

That’s never been the problem.

The problem starts the moment the signal leaves the water and tries to travel inland. That’s where everything collapses.

Bookmark this tweet right now.

Not after reading. Now.

At some point, you will build a payment system, work on one, or inherit one that is already broken.

When something goes wrong, and it will, you will need exactly what I am about to show you.

This is the most complete payment system breakdown I have ever written.

Every flow. Every edge case. Every trap. One thread In 2023, I built a payment system for a marketplace.

First month: ₦127 million processed.

I was celebrating.

Then my finance person called.

“Stephen, the numbers don’t add up. There’s a ₦4.3 million discrepancy.”

No duplicate charges. No missing webhooks. No obvious bug.

Just ₦4.3 million sitting somewhere between the user’s bank and my merchant wallet.

Unaccounted for.

I aged five years that week.

Let me save you from that. 👇

A startup spent 18 months building a product for Nigeria
launched it, got press, investors were happy, the team was proud
then something happened that nobody in that office saw coming... The first week after launch the numbers looked great
downloads were coming in, signups were going up, everyone was celebrating
then the support messages started
"the app keeps loading" "I can't submit the form" "it just shows blank screen"
the team was confused because on their end everything was working perfectly fine

A Nigerian fintech startup lost ₦47 million in one night.
Not to hackers. Not to fraud.
To one missing line of code.
Every backend dev in Nigeria needs to see this It was 2am. Their support inbox was on fire.
Users calling, screaming, money left their wallets, nothing reached the recipient.
The on-call dev opens the logs and sees thousands of silent failures stretching back to 9pm.
No alert. No rollback. Nothing.

Two years ago, a developer I know launched a small product here in Nigeria.

Everything was going fine.

Users were signing up, logging in, and using the platform daily.

Then one morning he woke up to something strange.

Several users were complaining their accounts had been accessed… without their permission.

Kindly bookmark for yourself and retweet so others too can learn Nothing looked wrong at first.

Passwords weren’t leaked.
Database wasn’t breached.
Servers weren’t compromised.

Yet attackers were somehow acting as legitimate users.

Which raised a bigger question:

If the credentials were safe… how were the attackers getting in?

Last year a junior developer built an app that suddenly went viral.

Everything was working perfectly… until 200,000 users showed up at the same time.

The server crashed.
The database froze.
Users couldn’t log in.
The product died in 6 hours.
Weeks later he interviewed at a big tech company.

They asked him one question:

“How would you design a system that can handle 1 million users?”

He failed the interview.

Not because he couldn’t code.

Because he didn’t understand system design.

This thread will explain system design so simply that when you face this question in an interview, you’ll know exactly what to say.

Bookmark and retweet this. You’ll need it someday. Most developers prepare for interviews by grinding:

• LeetCode
• Algorithms
• Framework questions
But senior engineering interviews often care more about one thing:
Can you design a system that scales?

A friend of mine walked into a backend interview feeling confident.

10 minutes in, the interviewer asked:

“What actually happens when you type a website URL and press Enter?”

He froze.

Not because it was hard… but because nobody ever explained it simply.

So here are backend interview questions explained in plain English.

Bookmark this. Retweet for others preparing. What happens when you type a website URL and press Enter?

Example: google.com

Here’s the simple flow:

• Your browser asks DNS for the website’s IP address
• DNS responds with the server location
• Your browser sends a request to that server
• The server sends back HTML, CSS, and JavaScript
• Your browser renders the webpage

Simple chain:

Name → Address → Request → Response → Page loads.