DEV Community: Michael Onoja

We Built to 100K Users on $20/Month. Now We're Migrating to Azure (And I'm Terrified)

Michael Onoja — Mon, 08 Dec 2025 14:20:41 +0000

Three years ago, I made a bet: We could build a social commerce platform serving Nigeria on a single budget VPS. No cloud. No auto-scaling. Just me, a server, and a lot of optimization.

That bet paid off. We scaled to 102,000 users, processed around 2 million monthly events, and maintained roughly 99.2% uptime.

Now I'm about to reverse that bet. In Q1 2026, we're migrating everything to Azure.

This post isn't about our technical wins (I cover the architecture in another article). This is about the mistakes we made, the technical debt I'm now paying for, and the fears that wake me up thinking about this migration.

If you're a solo founder or small team considering "should I start with cloud or build lean first?" — this is for you.

The Decision That Started Everything

December 2021: The Budget Reality

We raised about ₦15 million (roughly $10,000 USD). In Silicon Valley, that's a weekend's AWS bill. For us in Nigeria, it needed to last 18 months.

We ran the numbers.

Option A: AWS from Day One (rough estimate)

t3.medium instance: ~$40/month
RDS MySQL: ~$50/month
S3 + CloudFront: ~$30/month
Data transfer: ~$20/month

Total: ~$140/month ≈ $2,520 over 18 months

Option B: Budget VPS

VPS hosting: $20/month
Domain: $12/year
SSL: Free (Let's Encrypt)

Total: ~$20/month ≈ $360 over 18 months

Savings: roughly $2,160

That $2,160 was:

6 months of a junior developer, or
User acquisition for thousands of users, or
A few extra months of runway

I chose Option B.

At the time, it felt smart. Today, I'm not so sure.

What We Got Right

1. I Became a Really Good Optimizer

When you can't throw money at problems, you learn to actually solve them.

Example: Our feed query

Started at: ~6.4 seconds (joining 7 tables)
Optimized to: ~280 ms (denormalized + caching)

If I'd been on AWS, I might have just:

Upgraded the database instance
Added read replicas
Thrown a managed cache at it

Instead, I learned:

How MySQL query planning actually works
When denormalization makes sense
Strategic caching patterns
Proper indexing

That made me a better engineer.

2. I Understood Every Bottleneck

When your server crashes, you don't have a DevOps team to call. You are the DevOps team.

Example: The image upload disaster

Synchronous image processing was holding connections for 8–15 seconds. At 50K users, this killed the server.

On a fully managed stack, I might have just:

Scaled horizontally
Never understood why it was slow
Accumulated more inefficient code

Instead, I learned:

Async job processing
Queue management
Background workers
Resource optimization

That gave me a deep understanding of the system.

3. We Actually Made Money

Rough current metrics:

Revenue: ₦850,000/month
Infrastructure cost: ₦25,000/month
Infrastructure margin: 97%

On a heavier cloud stack at this stage, those margins would likely have been much thinner.

For a bootstrapped team, that difference mattered.

What I Got Wrong

1. I Built Technical Debt Into the Architecture

The mistake: Everything runs on one server.

Single VPS:
├── Web server (Nginx)
├── Application (Laravel)
├── Database (MySQL)
├── Cache (Redis)
├── Queue workers
└── Cron jobs

This works… until something breaks. Then everything breaks.

What I should have done (even on bare metal):

Separate the database
Separate Redis
Separate app and background workers
At least design with separation in mind

Now I have to untangle this while keeping 102K users online.

2. I Avoided Managed Services Too Long

The mistake: I manage everything manually.

Things I do by hand:

Database backups (daily scripts)
Security updates (manual apt-get)
SSL renewal (Let's Encrypt automation I maintain)
Log rotation and retention
Monitoring scripts and alerting bots

Time spent on ops per week: 8–12 hours.

Even on a budget, some managed pieces would have been worth it:

Managed backups
Automated security patching
Proper observability

Those 8–12 hours each week are expensive at CTO rates.

3. I Optimized for the Wrong Metric

The mistake: I optimized for server cost, not business cost.

Hosting cost saved: $2,160 over 18 months.

What I didn't do because I was babysitting infrastructure:

Ship a better iOS/Android experience sooner
Implement marketplace v2 earlier
Add real-time notifications
Build proper internal analytics
Focus on expansion outside our first market

The opportunity cost is easily larger than the hosting savings.

4. I Accumulated Monitoring Debt

My monitoring started like this:

#!/bin/bash
curl -f http://localhost/health || telegram_alert "Server down!"

It works, but it only tells me:

That something broke
After users start to feel it

What it doesn't tell me:

Why it broke
What's slow
How things are trending over time

Proper observability (like Application Insights or similar) would have caught a lot earlier what I currently discover from user complaints.

5. I Have No Tested Disaster Recovery Plan

I do have backups:

mysqldump --all-databases > backup.sql
rsync backup.sql user@backup-server:/backups/

What I hadn't done (for a long time):

Regular restore tests
Measured recovery time
Documented recovery steps
Considered geographic redundancy

That's not a real DR strategy. That's just "I hope this file works when I need it."

Why I'm Migrating to Azure in 2026

It's not because the VPS stopped working. It's because I'm hitting ceilings.

Ceiling 1: Scaling Beyond ~150K Users

Current bottlenecks:

Single database struggling with writes
One server handling all traffic
Manual, error-prone scaling

To reach 500K+ users, I'll need:

Database replication or a more scalable database
Load balancing
Multiple app instances
CDN and distributed caching

You can build all this yourself on VPSs, but it's complex and fragile. Azure gives you managed building blocks for these patterns.

Ceiling 2: Operational Burden on One Person

Right now:

I'm the only person who can deploy
I'm the only person who can debug production
Real vacations are hard
3 AM alerts come to my phone

That doesn't scale.

On Azure, with managed services and clearer separation, more of the team can own operations, and the platform doesn't depend on me being awake.

Ceiling 3: We Can Now Afford Better Infrastructure

2021: every ₦1,000 mattered.
2025/2026: we have recurring revenue.

We can now justify:

$500–$800/month on infrastructure
Proper monitoring and logging
Managed database/caching
A lot less stress

It's time to graduate.

What Terrifies Me About This Migration

Fear #1: Cost Explosion

We've all heard stories like:

"We migrated to cloud. First month: $300. Second month: $1,200. Third month: $4,800. Someone left a test resource running."

My nightmare:

Misconfigured auto-scaling
No guardrails
Surprise bill that burns months of runway

Mitigation I'm planning:

Azure budgets and cost alerts
Internal hard limits on what we provision
Start with minimal services
Gradual scaling, not "all-in" from day one

I'll still be watching bills nervously at first.

Fear #2: Downtime During Migration

Our users rely on the platform:

~102K active users
500+ vendors earning income

A bad migration could literally pause people's livelihoods.

Mitigation:

Run VPS and Azure in parallel for a while
Gradual traffic shift (1% → 10% → 50% → 100%)
Clear rollback strategy

But there's always that "what if we missed something?" feeling.

Fear #3: Over-Engineering in the Cloud

Cloud makes it very easy to overdo things:

Too many databases
Overcomplicated microservices
Three different messaging systems
"Because we can" architecture

What we actually need:

App Service (compute)
Managed MySQL (or equivalent)
Redis (caching)
Blob Storage (files)
CDN (static assets)

Anything beyond that has to prove it's necessary.

Fear #4: Vendor Lock-In

On VPS:

We can move providers in a day or two
Everything is relatively portable

On Azure:

We'll be using Azure-specific services and tooling
Moving away later will be harder

Mitigation:

Prefer standard protocols and services where possible
Avoid Azure-specific APIs until they're truly needed
Keep an exit strategy in mind

Vendor lock-in is real, and I want to go in with open eyes.

Fear #5: My Optimizations Becoming Problems

I've leaned heavily on:

Denormalization
Custom caching layers
Manual query tuning
Homegrown job orchestration

I worry about:

Which of these patterns will still make sense in a managed, distributed environment
Which optimizations might become unnecessary or even harmful

Some will transfer directly. Some I'll need to unlearn.

The Migration Plan (3 Phases, 6 Months)

Phase 1: Hybrid Mode (Q1 2026)

Budget: $100–$150/month

Move to Azure:

Azure CDN (static assets)
Azure Blob Storage (uploads)
Application Insights (observability)

Stay on VPS:

Application server
Database
Redis
Background jobs

Goal: learn Azure on low risk, measure impact.

Phase 2: Compute Migration (Q2 2026)

Budget: $300–$500/month

Move to Azure:

Azure App Service (application)
Azure Database for MySQL
Azure Cache for Redis

Keep on VPS temporarily:

Background jobs and some cron tasks

Goal: main user traffic on Azure; VPS as safety net.

Phase 3: Full Cloud (Q3 2026)

Budget: $500–$800/month

Move to Azure:

Azure Functions (background processing)
Azure Service Bus (job queue, if needed)
Remaining services

Retire:

VPS entirely

Goal: cloud-native, managed, and much less manual ops.

Questions I Need Answered

If you've migrated from self-hosted to Azure (or AWS), I'd love your input:

1. Cost Management

How do you prevent cost surprises?
Which Azure services tend to cause unexpected spend?
What cost optimizations do you apply from day one?

2. Migration Approach

Did you do lift-and-shift first or re-architect immediately?
What do you regret (either way)?

3. Downtime Risk

How did you handle database migration and cutover?
How did you validate the new stack before full switch?

4. What Broke

What worked fine on VPS / bare metal but broke in cloud?
Any issues with file system assumptions, cron jobs, or long-lived connections?

5. What You Wish You'd Known

Hidden costs (data transfer, logging, etc.)?
Region selection surprises?
Managed-service gotchas?

What I'm Learning

Lesson 1: "Start With Cloud" vs "Start Lean" Depends

If you're optimizing for:

Learning → VPS is great
Speed to market → Cloud is usually better
Cost at 1K users → VPS often wins
Cost at 100K users → Cloud may win
Your personal time → Cloud usually wins

Lesson 2: Technical Debt Is Real Debt

I saved about $2,160 on hosting.

I accumulated:

Manual ops burden (8–12 hours/week)
Delayed features
Fragile architecture
Migration complexity

For learning, I'd do it again. For business, the trade-off is less clear.

Lesson 3: Know When to Graduate

There's a time to:

Bootstrap and squeeze every resource
Invest in stability and scalability
Professionalize your infrastructure

I bootstrapped well. I might have stayed in that phase too long.

Lesson 4: Budget Constraints Teach You

Being forced to optimize made me better at:

Query optimization
Resource management
System design under constraints

I don't regret the VPS era. But I'm ready for the cloud era.

Resources Helping Me Plan

Learning:

Microsoft Learn: Azure fundamentals
Azure Architecture Center
Community posts, talks, and case studies

Tools:

Azure Pricing Calculator
Azure Cost Management (once live)
Terraform for infrastructure as code
Azure DevOps / GitHub Actions for CI/CD

Communities:

Microsoft Tech Community
Dev.to
Local Nigerian tech ecosystem

Connect:

Dev.to: @onoja5

If you're building for emerging markets, this is for you.I'm sharing the complete architecture that took Ayema from 0 to 100K users in Nigeria, including the mistakes, the midnight server crashes, and the technical decisions that actually mattered.

Michael Onoja — Sun, 30 Nov 2025 14:10:56 +0000

Michael Onoja

Nov 28 '25

Scaling to 100K Users: Architecture Lessons from Building Nigeria's Social Commerce Platform

#ai #programming #javascript #architecture

Comments 12

15 min read

How I Fixed a Website That Wouldn’t Open on GLO (Nigeria).The Complete Guide Nobody Told Me.

Michael Onoja — Sun, 30 Nov 2025 11:08:16 +0000

If you host websites as a Nigeria, especially on Namecheap with Cloudflare, you may eventually face the strange problem I faced:

Your website loads on MTN, Airtel, 9mobile, broadband, and VPN…

…but NOT on GLO.

Instead, you get:

ERR_CONNECTION_TIMED_OUT
Network error occurred
This site can’t be reached

But the craziest part?

cPanel works
Direct server IP works
VPN works
DNS is correct
SSL is fine
Server is online

Yet GLO refuses to open the domain.

This is exactly what happened to me, and after hours of deep testing, I found the true cause.

The Real Cause. Cloudflare’s Proxy + GLO Routing

Cloudflare has two modes:

🔶 Proxied (Orange Cloud)

Traffic passes through Cloudflare’s network → filtered → secured

⚪ DNS Only (Grey Cloud)

Traffic goes directly to your hosting server
No Cloudflare filtering or acceleration

Here’s the critical insight:

GLO’s network sometimes fails to reach Cloudflare’s orange-cloud proxy.

This means:

domain.com -> 🔶 Proxied  → fails on GLO
domain.com -> ⚪ DNS Only → works on GLO

The moment I turned off proxy for the root domain and the www record,
GLO visitors could instantly access the site again.

The Fix (Instant, Clean, and 100% Working)

1. Turn OFF Cloudflare Proxy (Orange → Grey)

Go to:

Cloudflare → DNS → Records

Change:

A Record:

Name: yourdomain.com
Proxy: 🔶 Proxied → ⚪ DNS Only

CNAME Record:

Name: www
Target: yourdomain.com
Proxy: 🔶 Proxied → ⚪ DNS Only

⏱ Wait 1–3 minutes
📶 Try again on GLO

💥 Solved.

2. Make Sure cPanel, Email & FTP Records Are DNS-Only

These must always be grey:

cpanel
webmail
whm
cpcontacts
cpcalendars
ftp
webdisk

If Cloudflare proxies them (orange):

Email fails
cPanel login fails
FTP fails
SSL fails
GLO access fails

Switch them to:

DNS Only (Grey Cloud)

How I Confirmed the Issue Was Cloudflare

VPN ON → Website opens

Direct IP → Opens

cPanel → Opens

GLO → Times out

This proved:

Server is fine
DNS is fine
Hosting is fine
SSL is fine
Only Cloudflare proxy was blocking GLO routing

Testing After the Fix

On GLO network (no VPN), visit:

https://yourdomain.com
https://www.yourdomain.com

If both load:

You fixed it.

My Cloudflare Firewall Rules (Safe for Nigerian Traffic)

Here are useful rules that protect your site WITHOUT blocking real users.

Block suspicious AJAX bot requests

(http.request.uri.path contains "/includes/ajax" 
and not http.user_agent contains "Mozilla")

Challenge high-risk countries

(ip.src.country in {"CN" "PK" "RU" "TR" "VN"})

Slow down homepage bot floods

(http.request.uri.path eq "/" and not cf.client.bot)

These reduce load without affecting Nigeria’s ISPs.

Can I Still Use Cloudflare? Yes.

Even with DNS-only:

Your DNS is faster
Your SSL is still managed
Firewall rules still work
Turnstile CAPTCHA still works
Analytics still works

You only lose:
Cloudflare WAF + CDN caching
(which you can re-enable later with Cloudflare Pro)

Why Not Keep Cloudflare Proxied?

If you want Cloudflare Proxy and Nigeria reliability:

→ Upgrade to Cloudflare Pro

Pro has better routing for Nigerian ISPs.

Final Thoughts

If your site:

Loads on MTN / Airtel / WiFi
Loads on VPN
Loads on direct IP
Does NOT load on GLO

The solution is simple:

Turn OFF Cloudflare proxy (orange → grey)
Make sure www is also grey
Fix your cPanel/email DNS records

That’s it.

This simple fix saved me hours. I hope it saves you too.

About the Author

**A Senior Software Engineer, DevOps Specialist, and Co-founder of Ayema Networks.I builds and scales digital platforms, optimizes infrastructure, and publishes real-world DevOps/Cloudflare guides to help developers across Africa solve tough hosting problems quickly.

Scaling to 100K Users: Architecture Lessons from Building Nigeria's Social Commerce Platform

Michael Onoja — Fri, 28 Nov 2025 16:18:55 +0000

How We Scaled Nigeria's Social Commerce Platform to 100K Users (And The Architecture That Almost Broke)

I still remember the night our server crashed at 3 AM. We'd just hit 50K users, and I was convinced we'd made a terrible architecture decision six months earlier. Turns out, I was both right and wrong.

Let me tell you the real story of building Ayema, Nigeria's homegrown social commerce platform, from zero to 102,000 active users, 2 million engagement events, and actually getting vendors paid for their content and product. This isn't going to be a sanitized case study. I'm going to show you what worked, what failed spectacularly, and the specific technical decisions that made the difference.

The Problem We Set Out to Solve

Here's the thing about building tech in Nigeria: the infrastructure challenges force you to make different choices than developers in Silicon Valley.

Nigerian vendors, creators and small businesses were stuck using global platforms that:

Assumed consistent high-speed internet
Optimized for desktop and mobile experiences (90% of our market is mobile)
Handled payments through systems not integrated with local banks
Didn't understand the social commerce culture here

We needed to build something different. A platform where a Kogi based fashion designer could post content, sell products, and actually get paid, all within one ecosystem that works on 4G connections.

The Initial Architecture Decision (That Everyone Questioned)

When we started designing Ayema's architecture in 2021, we made a controversial choice: I went with PHP/Laravel instead of the trendy Node.js/React full-stack everyone was using.

My co-founder literally asked me: "Are you sure? PHP?"

Here's why I made that call:

Backend: PHP/Laravel

Architecture:
- Laravel 8+ (now on 10)
- Modular API structure
- MySQL database
- VPS: 6GB RAM, 120GB SSD, 2.93TB bandwidth

Why Laravel worked for us:

Mature ecosystem - When you're building in Nigeria, you can't afford to debug framework issues at 2 AM. Laravel's maturity meant fewer surprises.
Eloquent ORM - Managing relationships between users, posts, products, transactions, and payments would have been hell with raw SQL. Eloquent made it elegant:

// Getting a user's posts with products and payment status
$posts = Post::with(['products', 'transactions.payment'])
    ->where('user_id', $userId)
    ->whereHas('products', function($query) {
        $query->where('status', 'active');
    })
    ->latest()
    ->paginate(20);

Built-in features we needed immediately - Authentication, job queues, event broadcasting. We didn't have time to wire these together from scratch.
Modular from day one - We structured it so each major feature (social, marketplace, payments, content monetization) lived in its own module. When we hit scaling issues, we could optimize individual parts without refactoring everything.

Frontend: ReactJS + Blade Templates

Yes, we're using both. And yes, it's intentional.

ReactJS for the dynamic social features:

Real-time post feeds
Interactive comments and reactions
Marketplace product browsing

Blade templates for:

Static pages (faster load times)
SEO-critical content
Admin dashboard (doesn't need SPA complexity)

Here's the controversial part: we serve a hybrid. Critical user paths are ReactJS for interactivity. Everything else? Server-rendered Blade templates.

Why? Because a 2MB React bundle takes 30+ seconds to load on spotty 3G. A 50KB Blade-rendered page? 2 seconds.

// Our React entry point is lean
import React from 'react';
import ReactDOM from 'react-dom';
import Feed from './components/Feed';
import Marketplace from './components/Marketplace';

// Only hydrate specific islands, not the entire page
if (document.getElementById('feed-root')) {
    ReactDOM.render(<Feed />, document.getElementById('feed-root'));
}

if (document.getElementById('marketplace-root')) {
    ReactDOM.render(<Marketplace />, document.getElementById('marketplace-root'));
}

This "islands of interactivity" approach kept our initial page loads under 3 seconds even on slow connections.

The Database Design That Saved Us

At 10K users, our naive database structure started showing cracks. By 30K, queries were taking 8+ seconds. Here's what we learned the hard way:

Initial Mistake: Over-Normalization

My computer science professors would be proud of my original schema - perfectly normalized to 5NF. My users? They were getting timeout errors.

The problem: To load a user's feed, we were joining 7 tables:

SELECT * FROM posts
JOIN users ON posts.user_id = users.id
JOIN post_media ON posts.id = post_media.post_id
JOIN reactions ON posts.id = reactions.post_id
JOIN comments ON posts.id = comments.post_id
JOIN products ON posts.id = products.post_id
JOIN transactions ON products.id = transactions.product_id
WHERE ...

This query took 6.4 seconds at 50K users.

The Fix: Strategic Denormalization

I know, I know. But hear me out. We added computed columns and caching:

// Add cached counts to posts table
Schema::table('posts', function (Blueprint $table) {
    $table->integer('reactions_count')->default(0);
    $table->integer('comments_count')->default(0);
    $table->integer('shares_count')->default(0);
    $table->timestamp('last_activity_at')->nullable();
});

// Update these via database triggers and Laravel events
class PostReacted
{
    public function handle($event)
    {
        DB::table('posts')
            ->where('id', $event->post->id)
            ->increment('reactions_count');

        Cache::tags(['feed', "user:{$event->post->user_id}"])
            ->flush();
    }
}

Result? Feed queries dropped from 6.4 seconds to 280ms.

The lesson: Denormalization isn't dirty when you're serving real users on real infrastructure.

The 2AM Crisis: When 50K Users Broke Everything

Remember that crash I mentioned? Here's what happened:

11:43 PM - Everything's running smoothly

12:18 AM - Response times creep up to 2 seconds

1:34 AM - Database connection pool exhausted

2:47 AM - Complete platform outage

I woke up to 47 WhatsApp messages and a dead server.

The Root Cause

Our image upload system was synchronous. When a user uploaded a photo:

PHP received the file
Validated it (held the connection)
Resized it to 5 different sizes (held the connection)
Uploaded to storage (held the connection)
Updated database
Returned response

With 50K+ users posting images simultaneously, our server ran out of worker processes. New requests just... queued. Forever.

The Solution: Async Job Processing

We moved heavy operations to Laravel queues:

// Before - synchronous nightmare
public function uploadImage(Request $request)
{
    $image = $request->file('image');

    // This took 8-15 seconds per image
    $resized = $this->resizeImage($image, [
        'thumbnail' => [150, 150],
        'small' => [480, 480],
        'medium' => [720, 720],
        'large' => [1080, 1080],
    ]);

    $this->uploadToStorage($resized);

    return response()->json(['success' => true]);
}

// After - async, returns immediately
public function uploadImage(Request $request)
{
    $image = $request->file('image');

    // Store original, return immediately
    $tempPath = $image->store('temp');

    // Process async
    ProcessImage::dispatch($tempPath, auth()->id());

    return response()->json([
        'success' => true,
        'message' => 'Image processing...'
    ]);
}

Impact:

Upload endpoint response time: 8s → 340ms
Server capacity increased 4x
User experience: Instant feedback with background processing

The Payment Integration That Nearly Killed Our Momentum

Building payments in Nigeria is... special. We integrated with:

Paystack - Our primary payment gateway for card payments and bank transfers
Flutterwave - Secondary gateway for redundancy and alternative payment methods
Internal wallet system - For peer-to-peer transfers and creator earnings
Bank transfer verification - Manual and automated reconciliation

The challenge wasn't the payment providers - Paystack and Flutterwave are excellent, with solid APIs and great documentation. The challenge was building the business logic around multiple payment flows while staying compliant with Nigerian financial regulations.

The Architecture Challenge

Users could earn money from:

Content monetization (people reacting to their posts)
Product sales (via marketplace)
Affiliate commissions

And they needed to:

Withdraw to their bank accounts (via Paystack/Flutterwave)
Transfer to other Ayema users (internal wallet)
Pay vendors (escrow for marketplace transactions)

All while complying with SCUML (Special Control Unit against Money Laundering) regulations and maintaining accurate financial records.

Here's our wallet transaction table structure:

Schema::create('wallet_transactions', function (Blueprint $table) {
    $table->uuid('id')->primary();
    $table->foreignId('user_id')->constrained();
    $table->enum('type', [
        'content_earning',
        'product_sale',
        'affiliate_commission',
        'withdrawal',
        'refund'
    ]);
    $table->decimal('amount', 15, 2);
    $table->decimal('fee', 10, 2)->default(0);
    $table->string('status'); // pending, processing, completed, failed
    $table->string('reference')->unique();
    $table->string('payment_channel')->nullable(); // bank, wallet, etc
    $table->json('metadata')->nullable();
    $table->timestamp('processed_at')->nullable();
    $table->timestamps();

    $table->index(['user_id', 'status']);
    $table->index(['reference']);
    $table->index(['created_at']);
});

The key insight: Use UUIDs for transaction IDs. When reconciling with payment gateways, auto-incrementing IDs exposed how many transactions we were processing. UUIDs kept that private.

Integrating Multiple Payment Gateways

We use both Paystack and Flutterwave for redundancy and to give users options:

class PaymentService
{
    protected $providers = [
        'paystack' => PaystackProvider::class,
        'flutterwave' => FlutterwaveProvider::class,
    ];

    public function initiateWithdrawal($user, $amount, $bankDetails)
    {
        // Try primary provider first
        $provider = $this->getProvider('paystack');

        try {
            $transfer = $provider->transfer([
                'amount' => $amount * 100, // Convert to kobo
                'recipient' => $bankDetails['account_number'],
                'bank_code' => $bankDetails['bank_code'],
                'reason' => 'Ayema wallet withdrawal',
                'reference' => $this->generateReference(),
            ]);

            return $this->recordTransaction($user, $transfer, 'paystack');

        } catch (PaymentProviderException $e) {
            // Fallback to secondary provider
            Log::warning('Paystack failed, trying Flutterwave', [
                'error' => $e->getMessage()
            ]);

            return $this->initiateWithFlutterwave($user, $amount, $bankDetails);
        }
    }

    public function handleWebhook(Request $request, $provider)
    {
        // Verify webhook signature
        if (!$this->verifyWebhookSignature($request, $provider)) {
            return response()->json(['error' => 'Invalid signature'], 401);
        }

        $data = $request->all();

        // Handle different event types
        switch ($data['event']) {
            case 'charge.success':
                $this->handleSuccessfulPayment($data);
                break;

            case 'transfer.success':
                $this->handleSuccessfulWithdrawal($data);
                break;

            case 'transfer.failed':
                $this->handleFailedWithdrawal($data);
                break;
        }

        return response()->json(['status' => 'success']);
    }

    protected function verifyWebhookSignature($request, $provider)
    {
        $signature = $request->header('X-Paystack-Signature') 
                  ?? $request->header('verif-hash');

        $secret = $provider === 'paystack' 
            ? config('services.paystack.secret_key')
            : config('services.flutterwave.secret_hash');

        $computedSignature = hash_hmac('sha512', $request->getContent(), $secret);

        return hash_equals($computedSignature, $signature);
    }
}

Important lessons from payment integration:

Always verify webhook signatures - We had an incident where someone sent fake webhook calls trying to credit accounts. Signature verification saved us.
Idempotency is critical - Payment gateways sometimes send duplicate webhooks. Use unique references:

public function handleSuccessfulPayment($data)
{
    $reference = $data['data']['reference'];

    // Check if already processed
    if (WalletTransaction::where('reference', $reference)->exists()) {
        Log::info('Duplicate webhook received', ['reference' => $reference]);
        return;
    }

    // Process payment...
}

Handle failures gracefully - Sometimes withdrawals fail after money is debited. We implemented automatic refunds:

public function handleFailedWithdrawal($data)
{
    $reference = $data['data']['reference'];
    $transaction = WalletTransaction::where('reference', $reference)->first();

    if ($transaction && $transaction->status === 'processing') {
        // Refund to wallet
        WalletService::credit(
            $transaction->user_id,
            amount: $transaction->amount,
            type: 'refund',
            reference: "refund:{$reference}"
        );

        $transaction->update(['status' => 'failed']);

        // Notify user
        $transaction->user->notify(new WithdrawalFailed($transaction));
    }
}

Bank account verification before withdrawal - Both Paystack and Flutterwave provide APIs to verify account details. We call this before processing withdrawals to prevent sending money to wrong accounts:

public function verifyBankAccount($accountNumber, $bankCode)
{
    $response = Http::withHeaders([
        'Authorization' => 'Bearer ' . config('services.paystack.secret_key'),
    ])->get('https://api.paystack.co/bank/resolve', [
        'account_number' => $accountNumber,
        'bank_code' => $bankCode,
    ]);

    if ($response->successful()) {
        return [
            'valid' => true,
            'account_name' => $response->json('data.account_name'),
        ];
    }

    return ['valid' => false];
}

This prevents the frustrating experience of users withdrawing to wrong account numbers and losing money.

The Double-Entry Bookkeeping Pattern

To ensure money never vanished, we implemented double-entry bookkeeping:

class WalletService
{
    public function transfer($fromUser, $toUser, $amount, $type)
    {
        DB::transaction(function() use ($fromUser, $toUser, $amount, $type) {
            // Debit sender
            WalletTransaction::create([
                'user_id' => $fromUser->id,
                'type' => $type,
                'amount' => -$amount,
                'status' => 'completed',
                'reference' => $this->generateReference(),
            ]);

            // Credit recipient
            WalletTransaction::create([
                'user_id' => $toUser->id,
                'type' => $type,
                'amount' => $amount,
                'status' => 'completed',
                'reference' => $this->generateReference(),
            ]);

            // Update cached balances
            $this->updateBalance($fromUser);
            $this->updateBalance($toUser);
        });
    }
}

This pattern saved us during an incident where a payment gateway sent duplicate callbacks. Because we checked for unique references, no double-payments occurred.

Optimizing for Nigerian Internet Reality

The biggest lesson: You cannot build for Nigerian users the same way you build for US/European users.

Image Optimization Pipeline

Original images from users' phones were 3-8MB. Loading a feed of 20 posts meant 60-160MB of data. On a 500MB/month plan (common in Nigeria), that's... not going to work.

Our solution:

class ImageOptimizationPipeline
{
    public function process($image)
    {
        return Pipeline::send($image)
            ->through([
                RemoveEXIFData::class,      // Remove location/camera data
                ResizeToMax1080::class,     // Cap maximum dimension
                ConvertToWebP::class,       // 30% smaller than JPEG
                CompressTo75Quality::class, // Sweet spot for size/quality
                GenerateThumbnail::class,   // Instant previews
                UploadToCDN::class,         // Serve from nearest edge
            ])
            ->thenReturn();
    }
}

Results:

Average image size: 3.2MB → 180KB (94% reduction)
Feed load on 3G: 45s → 4.2s
User complaints about data usage: 89% reduction

API Response Compression

We implemented aggressive response compression:

// Middleware for API responses
public function handle($request, Closure $next)
{
    $response = $next($request);

    if ($request->expectsJson()) {
        // Minify JSON
        $content = json_encode(
            json_decode($response->getContent()),
            JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE
        );

        // Gzip if client supports it
        if (str_contains($request->header('Accept-Encoding'), 'gzip')) {
            $content = gzencode($content, 6);
            $response->header('Content-Encoding', 'gzip');
        }

        $response->setContent($content);
    }

    return $response;
}

API payloads dropped from ~120KB to ~22KB average.

The Infrastructure Setup

Here's our actual production setup:

Server Configuration

Provider: Custom VPS 
OS: AlmaLinux 8
RAM: 12GB
Storage: 120GB SSD
Bandwidth: 2.93TB/month
Virtualization: KVM

Why not AWS/Google Cloud?

Simple math:

AWS t3.medium equivalent: $35-40/month + bandwidth costs
Our VPS: $25/month, all-inclusive
Savings over 2 years: $360+

At our stage, that money went into user acquisition instead.

Database Optimization

MySQL configuration tuned for our workload:

[mysqld]
# Connection pool
max_connections = 200
thread_cache_size = 16

# Buffer pool (4GB on 12GB server)
innodb_buffer_pool_size = 4G
innodb_log_file_size = 512M

# Query cache for repeated queries
query_cache_type = 1
query_cache_size = 256M

# Temp tables
tmp_table_size = 64M
max_heap_table_size = 64M

Combined with proper indexing:

// Critical indexes for feed queries
Schema::table('posts', function (Blueprint $table) {
    $table->index(['user_id', 'created_at']);
    $table->index(['status', 'created_at']);
    $table->index('last_activity_at');
});

Schema::table('reactions', function (Blueprint $table) {
    $table->index(['post_id', 'created_at']);
    $table->unique(['post_id', 'user_id']); // Prevent duplicate reactions
});

Caching Strategy

Three-tier caching:

Application cache (Redis) - User sessions, frequently accessed data
Query cache - MySQL query cache for repeated queries
Edge cache (Cloudflare) - Static assets and API responses with low mutation rates

// Example: Caching user profile data
public function getProfile($userId)
{
    return Cache::tags(['user', "profile:{$userId}"])
        ->remember("user.profile.{$userId}", 3600, function() use ($userId) {
            return User::with(['posts', 'products', 'followers'])
                ->findOrFail($userId);
        });
}

// Invalidate on profile update
public function updateProfile($userId, $data)
{
    $user = User::findOrFail($userId);
    $user->update($data);

    Cache::tags(["profile:{$userId}"])->flush();

    return $user;
}

Security & Compliance (The Boring But Critical Stuff)

Building a platform handling payments means you can't skip security. Here's what we implemented:

API Security

// Rate limiting per user
RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(120)->by($request->user()->id)
        : Limit::perMinute(20)->by($request->ip());
});

// Encrypted API endpoints
Route::middleware(['auth:sanctum', 'throttle:api', 'verify.signature'])
    ->group(function() {
        Route::post('/transactions', [TransactionController::class, 'create']);
    });

Data Protection (NITDA Compliance)

Nigeria's NITDA requires:

User consent for data collection
Right to data deletion
Secure storage of personal information

Our implementation:

class UserDataExportJob implements ShouldQueue
{
    public function handle()
    {
        $user = User::find($this->userId);

        $data = [
            'profile' => $user->only(['name', 'email', 'phone']),
            'posts' => $user->posts()->get(),
            'products' => $user->products()->get(),
            'transactions' => $user->transactions()->get(),
            'reactions' => $user->reactions()->get(),
        ];

        Storage::put(
            "exports/user-{$user->id}-" . now()->timestamp . ".json",
            json_encode($data, JSON_PRETTY_PRINT)
        );

        // Send download link to user
        Mail::to($user)->send(new DataExportReady($exportPath));
    }
}

SSL & Encryption

All data in transit encrypted via SSL certificates (Let's Encrypt):

# Auto-renewal script
certbot renew --nginx --non-interactive --agree-tos

Database credentials encrypted using Laravel's built-in encryption:

config([
    'database.connections.mysql.password' => 
        decrypt(env('DB_PASSWORD_ENCRYPTED'))
]);

Monitoring & Debugging at Scale

At 100K users, you can't manually check if things are working. We automated everything:

Application Monitoring

// Custom monitoring middleware
class PerformanceMonitor
{
    public function handle($request, Closure $next)
    {
        $start = microtime(true);

        $response = $next($request);

        $duration = (microtime(true) - $start) * 1000;

        // Log slow requests
        if ($duration > 1000) {
            Log::warning('Slow request detected', [
                'url' => $request->fullUrl(),
                'method' => $request->method(),
                'duration' => $duration,
                'user_id' => auth()->id(),
                'ip' => $request->ip(),
            ]);
        }

        // Track metrics
        Metrics::increment('api.requests', [
            'endpoint' => $request->path(),
            'status' => $response->status(),
        ]);

        Metrics::histogram('api.response_time', $duration, [
            'endpoint' => $request->path(),
        ]);

        return $response;
    }
}

Error Tracking

Every exception gets logged with context:

app()->bind(ExceptionHandler::class, function ($app) {
    return new class($app) extends Handler {
        public function report(Exception $exception)
        {
            if ($this->shouldReport($exception)) {
                Log::error($exception->getMessage(), [
                    'exception' => get_class($exception),
                    'file' => $exception->getFile(),
                    'line' => $exception->getLine(),
                    'trace' => $exception->getTraceAsString(),
                    'user_id' => auth()->id(),
                    'url' => request()->fullUrl(),
                    'input' => request()->except(['password']),
                ]);
            }

            parent::report($exception);
        }
    };
});

Automated Alerts

// Send Telegram alert for critical issues
if ($exception instanceof DatabaseConnectionException) {
    Http::post('https://api.telegram.org/bot' . env('TELEGRAM_BOT_TOKEN') . '/sendMessage', [
        'chat_id' => env('TELEGRAM_ADMIN_CHAT'),
        'text' => "🚨 DATABASE DOWN\n\n" .
                  "Time: " . now() . "\n" .
                  "Error: " . $exception->getMessage(),
    ]);
}

The Features That Drove Growth

Technical architecture alone doesn't get you 100K users. Here's what actually drove adoption:

1. Content Monetization That Actually Works

Unlike global platforms where only mega-influencers make money, we enabled monetization from day one:

// User earns when someone reacts to their post
class ReactionController extends Controller
{
    public function react(Post $post)
    {
        $reaction = Reaction::create([
            'post_id' => $post->id,
            'user_id' => auth()->id(),
            'type' => request('type'), // like, love, wow, etc
        ]);

        // Creator earns ₦1 per reaction
        WalletService::credit(
            $post->user_id,
            amount: 1.00,
            type: 'content_earning',
            reference: "reaction:{$reaction->id}"
        );

        // Notify creator
        $post->user->notify(new EarnedFromContent($reaction));

        return response()->json(['success' => true]);
    }
}

This simple feature drove engagement because creators could actually see real money from their content.

2. The Free Internet Initiative

This was my idea: Partner with institutions to provide free Wi-Fi powered by Starlink, branded with Ayema.

The setup:

We pay for Starlink hardware and subscription
Institution provides physical space
Users connect through Ayema-branded portal
They discover the platform naturally

Results at Ahmadu Bello University, Zaria:

8,000+ students connected
2,400 signed up for Ayema
30% conversion rate (insane for organic growth)
Cost per acquisition: ₦830 (vs ₦2,500 for paid ads)

The technical implementation was straightforward - captive portal redirecting to our registration:

// Captive portal detection and redirect
if (window.location.hostname === 'captive.ayema.ng') {
    // User is on WiFi login page
    const params = new URLSearchParams(window.location.search);
    const mac = params.get('mac');
    const ap = params.get('ap');

    // Track unique device
    fetch('/api/wifi/connect', {
        method: 'POST',
        body: JSON.stringify({ mac, ap, location: 'abu-zaria' })
    });

    // Redirect to signup with pre-filled referral
    window.location.href = '/register?source=wifi-abu';
}

3. Integrated Marketplace with Real Shipping

Nigerian SMEs couldn't easily sell online. Most platforms either:

Required technical skills to set up
Charged fees
Didn't integrate local logistics

We built it directly into the social feed:

// User posts a product, it appears as a feed item
class ProductPost extends Post
{
    public function toFeedItem()
    {
        return [
            'type' => 'product',
            'id' => $this->id,
            'user' => $this->user->profile(),
            'content' => $this->description,
            'product' => [
                'name' => $this->product->name,
                'price' => $this->product->price,
                'images' => $this->product->images,
                'in_stock' => $this->product->stock > 0,
                'shipping_available' => $this->product->ships_nationwide,
            ],
            'created_at' => $this->created_at,
            'reactions_count' => $this->reactions_count,
            'comments_count' => $this->comments_count,
        ];
    }
}

Sellers could post a product like they post regular content. Buyers could purchase directly in the feed. No context switching.

The Metrics That Matter

After 12 months, here's where we stand:

User Engagement

102,000 active users (users who opened the app in last 30 days)
2 million engagement events (posts, reactions, comments, purchases)
695,000 page views
Average session duration: 8.4 minutes
Daily active users: 31,000 (30% DAU/MAU ratio)

Platform Performance

99.2% uptime
Average API response time: 340ms
Image load time: 1.8s average
Database query time: 180ms average

Commercial Success

₦25 million in total funding received
500+ active vendors on marketplace
4.8★ rating on Google Play Store (1,000+ downloads)
Google AdSense approved (earning USD from international ads)

Infrastructure Efficiency

Cost per user: ₦180/month (including hosting, bandwidth, storage)
Server costs: ₦25,000/month ($25 USD)
CDN costs: ₦8,000/month (Cloudflare free tier + paid features)

What I'd Do Differently

Building with hindsight is easy, but here are genuine mistakes I'd fix:

1. Start with Proper Testing Earlier

We didn't write tests until we had 20K users. Big mistake. When we finally added tests:

class PaymentTest extends TestCase
{
    /** @test */
    public function user_can_withdraw_funds()
    {
        $user = User::factory()->create(['wallet_balance' => 5000]);

        $response = $this->actingAs($user)
            ->post('/api/withdrawals', [
                'amount' => 2000,
                'bank_code' => '058',
                'account_number' => '0123456789',
            ]);

        $response->assertStatus(200);
        $this->assertEquals(3000, $user->fresh()->wallet_balance);
        $this->assertDatabaseHas('wallet_transactions', [
            'user_id' => $user->id,
            'amount' => -2000,
            'type' => 'withdrawal',
        ]);
    }
}

This test would have caught a bug where failed withdrawals still deducted money from user wallets. We only found it after 12 users reported it.

2. Implement Feature Flags from Day One

Rolling back a broken feature meant deploying code. With feature flags, we could toggle features:

// Should've used this pattern from the start
if (Feature::active('marketplace-v2')) {
    return view('marketplace.v2');
} else {
    return view('marketplace.v1');
}

Would have saved us during the "marketplace redesign that broke everything" incident.

3. Think About Mobile Data Costs Earlier

We optimized for data after launching. Should have been core from day one. Every feature should answer: "How much data does this use?"

Lessons for Builders in Emerging Markets

If you're building for Nigeria, or similar markets:

1. Internet Assumptions

Don't assume:

✗ Consistent broadband connections
✗ Unlimited data plans
✗ Users on latest devices

Instead, design for:

✓ Intermittent 3G/4G
✓ 500MB - 2GB monthly data budgets
✓ Android devices from 2018-2020

2. Payment Integration

Don't assume:

✗ Credit card prevalence
✗ Simple payment flows
✗ Instant settlements

Instead, design for:

✓ Bank transfers as primary method
✓ Manual reconciliation processes
✓ 24-48 hour settlement delays

3. User Behavior

Don't assume:

✗ Users read instructions
✗ Users understand technical jargon
✗ Users want complex features

Instead, design for:

✓ Intuitive, icon-based interfaces
✓ Familiar patterns from WhatsApp/Facebook
✓ Simple flows with clear outcomes

The Tech Stack Summary

For those who want the TL;DR:

Backend:

PHP 8.1 / Laravel 10
MySQL 8.0
Redis for caching and queues
Laravel Sanctum for API authentication

Frontend:

ReactJS 18 for interactive components
Blade templates for static content
Tailwind CSS for styling
Axios for API calls

Infrastructure:

VPS (AlmaLinux 8, 12GB RAM, 120GB SSD)
Cloudflare for CDN and DNS
Let's Encrypt for SSL
Starlink for initiative WiFi

DevOps:

Git for version control
GitHub Actions for CI/CD
Laravel Forge for server management
Daily automated backups

Monitoring:

Custom logging to files + database
Telegram for critical alerts
Google Analytics for user behavior

Open Sourcing Components

I'm working on open-sourcing parts of our stack:

Image optimization pipeline - The entire flow from upload to CDN
Wallet system - Double-entry bookkeeping for Laravel
Feed algorithm - Our approach to relevance ranking
Offline-first PWA utilities - For handling intermittent connections

Follow me here on Dev.to and on GitHub for updates.

What's Next for Ayema

Our roadmap for the next 12 months:

Technical

[ ] Migrate to microservices (social, marketplace, payments as separate services)
[ ] Implement GraphQL for more efficient mobile data usage
[ ] Build native iOS app (currently using web wrapper)
[ ] Add offline-first capabilities (service workers + IndexedDB)
[ ] Real-time notifications via WebSockets

Product

[ ] Launch Ayema Pay (standalone wallet app)
[ ] Ayema Ride (ride-hailing integration)
[ ] Digital Library (textbooks and educational content)
[ ] Bill payments (airtime, data, electricity)
[ ] Expand to Ghana, Kenya, South Africa

Scale

[ ] Target: 500,000 active users by Q4 2026
[ ] 10,000+ active vendors
[ ] ₦100 million annual revenue
[ ] Partner with 50+ institutions for WiFi initiative

Final Thoughts

Building Ayema taught me that great architecture isn't about using the latest tech. It's about understanding your users' reality and making technical decisions that serve them.

We didn't use Kubernetes, or microservices, or serverless functions. We used boring, proven technology and focused on solving real problems:

Slow internet? Optimize everything for data usage
Payment complexity? Build simple flows with clear feedback
Limited reach? Partner with institutions for physical access points

If you're building something similar, my advice:

Start simple - Monolith > microservices until you know your bottlenecks
Measure everything - You can't optimize what you don't measure
Talk to users - Your assumptions about their needs are probably wrong
Deploy fast - Perfect code that ships in 6 months loses to good code that ships in 2 weeks
Optimize for iteration speed - Ability to fix things quickly > having no bugs

Let's Connect

I'm always happy to talk architecture, scaling challenges, or building for emerging markets:

Twitter/X: @michaelokonja
LinkedIn: Michael Okpotu Onoja
Email: michael.onoja@ayema.ng
Try Ayema: https://ayema.ng, Download on Google Play | Download on App Store

Have questions about our architecture? Drop them in the comments. I'll answer every single one.

Tags: #webdev #architecture #scaling #laravel #php #reactjs #startup #africa #socialmedia #ecommerce