Building for Scale: Architecture Lessons from Nigerian Fintech

After helping several Ikenga portfolio companies scale their systems, I've seen patterns emerge. Here's what works—and what doesn't—when building for Nigerian market conditions.

The Unique Challenge

Building in Nigeria means building for conditions that would be considered edge cases elsewhere:

• Unreliable connectivity: Users drop in and out of coverage constantly
• High latency: Network round trips can be 10x what you'd see in developed markets
• Device diversity: From flagship smartphones to feature phones with 512MB RAM
• Power constraints: Users are battery-conscious in ways Western users aren't

Your architecture must account for all of this.

Lesson 1: Embrace Eventual Consistency

The traditional request-response model breaks in high-latency environments. Instead:

# Bad: Synchronous confirmation
POST /payment → Wait for bank → Wait for notification → Return success

# Good: Async with webhooks
POST /payment → Return pending → Background processing → Webhook/SMS on completion

Users are surprisingly accepting of "processing" states if you communicate clearly. They're not accepting of timeouts and failures.

Implementation Pattern

Use event-driven architecture with persistent queues:

1. Accept request immediately
2. Store in durable queue (Redis + disk persistence, or proper message queue)
3. Process asynchronously
4. Notify on completion via multiple channels (push, SMS, in-app)

Lesson 2: Design for Offline-First

Every app should function meaningfully without internet. This means:

• Local-first data: Store what you can locally
• Optimistic UI: Assume success and reconcile later
• Sync queues: Queue user actions for when connectivity returns
• Conflict resolution: Have strategies for when local and server state diverge

We've seen apps increase engagement 40%+ just by improving offline behavior.

Lesson 3: Right-Size Your Infrastructure

The temptation is to over-engineer for scale you don't have yet. Resist it.

Early Stage (< 1000 DAU)

• Simple monolith on a single VPS
• Managed database (RDS/Cloud SQL)
• Simple queue (even a database table)
• Direct bank integrations

Growth Stage (1K - 50K DAU)

• Start splitting services where bottlenecks appear
• Add caching layer (Redis)
• Proper message queue (RabbitMQ/SQS)
• Payment aggregator vs. direct integrations

Scale Stage (50K+ DAU)

• Full microservices where needed
• Multi-region deployment for resilience
• Event sourcing for critical paths
• Multiple payment providers for redundancy

Lesson 4: Idempotency Is Non-Negotiable

In unreliable networks, requests get retried. A lot. If your system isn't idempotent, you'll have:

• Double charges
• Duplicate records
• Angry users

The Pattern

// Every mutation request needs an idempotency key
async function processPayment(idempotencyKey, paymentDetails) {
  // Check if we've seen this request before
  const existing = await redis.get(`idemp:${idempotencyKey}`)
  if (existing) {
    return JSON.parse(existing) // Return cached result
  }
  
  // Process the payment
  const result = await actuallyProcessPayment(paymentDetails)
  
  // Cache the result
  await redis.setex(`idemp:${idempotencyKey}`, 86400, JSON.stringify(result))
  
  return result
}

Lesson 5: SMS Is Infrastructure

Push notifications fail. Apps get uninstalled. Phone numbers persist.

Critical notifications should always have SMS fallback:

• Transaction confirmations
• OTPs (obviously)
• Important state changes

Yes, it costs money. Budget for it.

Lesson 6: Monitoring in Low-Trust Environments

You can't trust your metrics if your infrastructure is unreliable. Build for this:

• Distributed tracing: Every request needs a trace ID that follows it through all systems
• External monitoring: Don't just monitor from inside your infrastructure
• Business metrics alongside technical: Transaction success rate matters more than p99 latency
• Alerting with context: An alert should contain everything needed to diagnose the issue

Lesson 7: Security for High-Stakes Transactions

Financial applications in Nigeria face sophisticated fraud. Baseline security isn't enough.

Must-Haves

• Device fingerprinting
• Behavioral biometrics (typing patterns, usage patterns)
• Velocity checks (frequency limits)
• Graph analysis for connected accounts
• Real-time fraud scoring

Common Attacks We See

• SIM swap (mitigate with multi-factor beyond SMS)
• Social engineering (train your support team)
• API abuse (rate limiting + abuse detection)
• Account takeover (session management + anomaly detection)

The Meta-Lesson

Building in Nigeria teaches you to build resilient systems. The constraints force good engineering.

Companies that master building for Nigerian conditions find themselves well-prepared for any market. The skills transfer.

Resources

Some tools we've found valuable:

• Monitoring: Datadog, Sentry, custom Prometheus stacks
• Queues: RabbitMQ for most cases, Kafka for high-throughput
• Caching: Redis (properly configured for persistence)
• Mobile: React Native with good offline libraries, or well-architected native

Tunde Adeyemi is a Technical Advisor at Ikenga Foundry, helping portfolio companies scale their systems. Previously, he led engineering at a major Nigerian fintech.