If you are building ANY app, website, SaaS, AI tool or digital product used by people in Nigeria OR Europe, this can save you from massive fines in 2026.

Exact compliance checklist for NDPA + GDPR: documents you MUST have, where they apply to your build, plus clear Do’s and Don’ts.

Extremely practical for founders.

Save & share! GDPR fines regularly reach hundreds of millions of euros.

Nigeria’s NDPC is now investigating and fining tech companies and banks fast.

If your product touches names, emails, IPs, locations, payments or any user data from these regions, you are probably regulated.

Non-compliance kills startups.

A Nigerian healthtech/fintech startup built an app that processes patient medical records plus financial and payment data.

They hit 18k users fast and raised decent pre-seed funding.

Then NDPC and NCC both came knocking for overlapping violations on data protection, telecom rules, and health data handling.

The company is now stuck in audits, facing massive exposure in 2026.

Here’s how multiple regulators overlap and why most founders get blindsided: First, understand this:

Health data is sensitive personal data under the Nigeria Data Protection Act.

Adding financial processing brings in extra layers from NDPC, NCC (for any communication features), and sometimes health-specific rules.

Founders think one privacy policy covers everything.

That is mistake number one.

Why Most Banking Systems Steer Clear of JavaScript Ecosystems for Core Operations ?
Let’s talk about it ( The Security Lag ) Banks handle trillions in assets, sensitive customer data, and operate under strict regulations such as PCI-DSS, GDPR, and Basel frameworks.

Yet when you look at the systems moving money, processing transactions, maintaining ledgers, and calculating risk, you rarely find JavaScript at the core.
Why?

It's not because JavaScript is "just a frontend language."

It's because banks optimize for risk reduction, predictability, and long-term security over developer velocity.

Might not be a 100% perfect roadmap.

But I genuinely believe if you follow this path properly, your system design knowledge will massively improve over time.

Most people jump into “design Uber” or “design WhatsApp” too early without understanding the foundations. Before touching system design, first become very comfortable building backend applications.

Not tutorials.
Not clone projects.
Real applications with:
Authentication
Payments
Uploads
Caching
Queues
Notifications
Webhooks
RBAC
Background jobs

You cannot design what you’ve never experienced building.

There are different types of message brokers.
And picking the wrong one can overcomplicate your entire architecture.

Not every system needs Kafka.
Not every workload fits RabbitMQ.
Not every async job should touch Redis Streams.

I’ll explain, let’s read RabbitMQ →
Best for reliable task queues.

Need:
• retries
• dead letter queues
• job acknowledgements
• ordered workers

Perfect for:
payments, emails, background jobs, OTP processing.

Backend Engineers throw Kafka into every architecture nowadays like it’s a compulsory tech stack.

Meanwhile, many applications genuinely do not need Kafka at all.

So, when exactly should Kafka actually be used? Asynchronous background processing at scale.

A user uploads a video, submits a huge report, or places an order.

You don’t want them waiting 10–30 seconds for processing.

Push the job into Kafka.
Consumers process it in the background while the API returns instantly.

This is how large platforms handle:
• Video encoding
• PDF generation
• Image resizing
• Email campaigns

“Who deleted the transactions?”

The engineering call went completely silent.

Because ₦187 million worth of transaction records had disappeared from production.

And nobody could explain how. At first, everybody assumed it was probably:

A frontend bug.
Cache issue.
Delayed replication.
Bad query.
Normal production drama.

Then, finance joined the call.

While building systems, engineers should choose databases with the mindset that not every data model will age gracefully with their application.

Most teams pick MongoDB because “it’s flexible.”
Others default to Postgres because “it’s reliable.”
Then the data layer becomes the bottleneck.

Choosing the right DB is designing your foundation so it doesn’t collapse under real usage. MongoDB wins when:

• Your data is naturally document-shaped
(User profiles, content, catalogs, configs)

• Schemas change frequently during rapid iteration

• You need true schema flexibility without painful migrations

• Horizontal scaling and sharding feel natural for your workload

One thing I’ve noticed is that a lot of people building Fintech applications actually do not understand how payment systems work.

So I made a list of 10 payment terms that most backend engineers trying to break into the Fintech space must know.

Would be helpful during interviews, too. Authorization

The bank approves the transaction and reserves the money.

Example:

You order an Uber.
Your card gets checked first before the trip ends.
Money is reserved.
Not fully collected yet.

Pelumi’s e-commerce backend was handling 200 users comfortably.

Then they ran a promo.

800 users hit the platform in 45 minutes.

The server didn’t crash because of traffic.

It crashed because of one line of code that had been sitting in the codebase since day one Pelumi had built a product listing page for her fashion marketplace.

NestJS backend.
Prisma ORM.
PostgreSQL database.
Clean architecture.
Well-structured code.
Everything looked perfect locally.

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.