It is a system design requirement, like scalability or availability.
If your architecture starts without threat modeling, you are already exposed.
First principle: STRIDE threat modeling.
Every component must be analyzed:
Spoofing
Tampering
Repudiation
Information disclosure
Denial of service
Elevation of privilege
Because in reality, every system has an attacker model, whether you define it or not.
Example they ignored:
A login endpoint like:
SELECT * FROM users WHERE email = '$email' AND password = '$password'
One input change:
' OR 1=1 --
And suddenly authentication is bypassed.
No password needed.
That’s SQL injection.
Still happening in 2026.
Another failure:
A transfer API that accepted:
{ amount, recipient, timestamp }
Attackers intercepted a valid request and replayed it multiple times.
Same payload. Different outcomes.
Result: one ₦10,000 transfer became ₦100,000 in seconds.
No nonce. No signature validation. No protection.
Then authentication cracks:
Session tokens never expired properly.
Attackers stole JWTs from compromised devices and reused them across IPs.
No device binding. No token rotation.
So even after password changes, access remained active.
That is not a bug.
That is broken auth design.
Fixing this requires more than patches.
You move to Zero-Trust Architecture:
mTLS between services
Short-lived tokens
Request signing (HMAC or asymmetric)
Replay protection using nonces + timestamps
Device-bound sessions
Every request must prove it belongs.
Minimum baseline if you’re not there yet:
Input validation everywhere
WAF with OWASP Core Rules
Prepared statements only
Strict CORS + CSP policies
Rate limiting at gateway
Dependency scanning (Snyk, Dependabot)
Security chaos testing
No shortcuts.
The startup rebuilt everything.
STRIDE modeling first.
Replay protection added.
SQL injection eliminated via strict ORM + prepared queries.
JWT system redesigned with rotation + expiration enforcement.
Anomaly detection introduced for transaction spikes.
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.
Let me explain a Nigerian scenario using what we’ve covered:
You transfer ₦50,000 using OPay.
Your account is debited.
The receiving bank has not updated yet due to network delay.
Now the system must decide:
Option 1: Consistency
Delay everything until all systems agree, meaning you won’t see the transaction immediately.
Option 2: Availability
Show success instantly, but the receiver might not see the money yet.
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.
The average Nigerian user is not Emeka in Yaba with a 5G SIM and a Samsung S24.
The average Nigerian user is Tunde in Ikorodu. Tunde has a Tecno Camon with 2GB RAM. He is on 1.5GB of data that he bought for ₦1,500. His battery is at 34 percent.
Then your app asks him to enable location services for a better experience.
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
The first thing I changed was the registration flow
Most people do email, then password, and call it a day
I went phone first
OTP verification before anything else
then email and password after
Because realistically, phone numbers are more reliable for identity in my environment, everyone has a phone number; most people ( old ones ) might have difficulties with emails
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.
A lot of what’s carrying your data across Nigeria isn’t even fiber buried underground.
It’s microwave. Tower to tower. Like a radio signal bouncing across the country.
Cheaper to deploy? Yes. But slower, congested, and breaks down in bad weather.
That’s why your internet gets worse every time it rains. Not network maintenance, so stop blaming these guys.