DEV Community: Korir Moses

Chauffeur Knowledge in Software Development: When Developers Sound Smart Without Deep Understanding

Korir Moses — Sun, 08 Feb 2026 07:16:55 +0000

Let's Be Honest

We've all been that developer in a meeting who confidently throws around terms like "event-driven architecture" or "CQRS pattern" while secretly hoping nobody asks us to explain what those actually mean.

I know I have.

There's a great old story that explains this perfectly: A famous scientist had a chauffeur who drove him to lectures across the country. After months of hearing the same speech, the chauffeur memorized it word-for-word. One day, he joked, "I could give that lecture myself!" The scientist, amused, let him try.

The chauffeur nailed it. Perfect delivery. Standing ovation.

Then someone asked a follow-up question.

The chauffeur froze.

This is what we call "chauffeur knowledge" in software development - and it's everywhere.

What Does This Actually Look Like?

The Buzzword Enthusiast

You know this person. Maybe you've been this person.

They walk into planning meetings with energy: "We need microservices! Event sourcing! Kubernetes!"

Someone asks, "Why?"

"Because... that's what successful companies use?"

Here's the thing: Netflix uses microservices because they have hundreds of developers and millions of users. Your internal tool has three developers and 200 users. You probably need a well-organized monolith, not a distributed nightmare.

But "microservices" sounds way cooler in your LinkedIn profile.

The Framework Wizard (Who Can't Explain JavaScript)

I once worked with a developer who could build beautiful React apps. Seriously impressive stuff. Then our Node.js backend started hanging randomly.

"It's probably the async calls," I suggested.

Blank stare.

"How do promises work?" I asked.

More blank stares.

They'd been building async apps for two years without understanding what async actually meant. The framework had hidden all the complexity - until it didn't.

The Stack Overflow Speedrunner

We've all done this. Production breaks, you Google the error, find a Stack Overflow answer, copy-paste the solution, push to prod.

It works! Ship it!

Three months later, the same bug appears under different conditions. Nobody on the team understands why the fix worked in the first place. You're back to Stack Overflow, finding another patch for your patch.

This is how legacy codebases are born.

The Architecture Tourist

"Let's build our system like Uber's!"

"Do we have Uber's problems?"

"Well... no. We have 10 concurrent users max."

"Do we have Uber's engineering team?"

"No, there's three of us."

"So why—"

"BECAUSE IT'S BEST PRACTICE."

We love copying what big tech does without asking if we actually need it. It's like buying a semi-truck when you need to move one couch.

Why Does This Happen? (And Why It's Not Entirely Our Fault)

Let's be real about why this happens:

The tech world moves insanely fast. Last week's hot framework is this week's legacy code. We feel like we're constantly playing catch-up, so we memorize instead of understand.

Imposter syndrome is real. Everyone else seems to know everything, so we fake it. We use complex words to hide that we're still figuring things out.

Interviews reward memorization. "Reverse a binary tree on a whiteboard" doesn't test understanding - it tests whether you memorized the solution the night before.

Deadlines are brutal. "Why does this work?" takes time we don't have. "Does this work?" is all that matters when you're shipping tomorrow.

Tools over fundamentals. Bootcamps teach React in week three. Nobody teaches how the browser actually works.

I get it. I've been there. We've all been there.

When Chauffeur Knowledge Bites Back

Here's where it gets painful:

That 3 AM production incident. Your beautifully copied solution breaks. You have no idea why. The Stack Overflow answer that saved you can't help you now. You're Googling frantically while users are locked out.

The performance disaster. You used that ORM everyone recommends. Suddenly your database is dying. Someone looks at the queries and finds you're doing 1,000 database calls per page load. You didn't know ORMs could do that because you never learned SQL.

The overengineered mess. You built microservices because Netflix does it. Now you have eight services talking to each other, deployment takes three hours, and debugging requires checking logs across multiple systems. Your team of three spends more time on DevOps than features.

The security hole. You copied an authentication pattern without understanding how tokens work. Turns out your app has been leaking user sessions for six months.

These aren't hypothetical. These happen every day.

How to Actually Get Better (Without Burning Out)

Start With "Why"

Before you implement anything, pause and ask:

"Why does this solution exist?"
"What problem is it solving?"
"What are the alternatives?"
"What breaks if I get this wrong?"

If you can't answer these, you're probably in chauffeur mode.

Learn the Boring Stuff

I know, I know. Learning HTTP fundamentals isn't as sexy as learning the new JavaScript framework. But here's the secret: frameworks change, fundamentals don't.

Learn how databases actually work. Learn how networks actually work. Learn how memory actually works.

That knowledge compounds. Every new tool you learn becomes easier because you understand what it's built on.

Build Something Stupid Simple

Want to really understand Express? Build a web server without it. Just raw Node.js HTTP handlers.

Want to understand Redux? Build simple state management from scratch.

Want to understand authentication? Implement basic JWT handling yourself.

You'll appreciate what frameworks do for you, and you'll know how to fix them when they break.

Say "I Don't Know" More Often

This is the hardest one.

In your next meeting, when someone asks about something you don't understand, try saying: "I don't know. Can you explain?"

I promise: half the room doesn't know either. They're just better at hiding it.

Good teams reward curiosity over fake confidence. If your team punishes "I don't know," you're on the wrong team.

Teach Someone Else

You think you understand dependency injection? Try explaining it to a junior developer.

Can't do it without hand-waving? You don't understand it yet.

Teaching forces you to organize your thoughts, find simple examples, and answer unexpected questions. It's the fastest way to find gaps in your knowledge.

A Confession

I wrote this article because I needed to read it.

Last month I confidently recommended a caching strategy in a code review. Someone asked me to explain the eviction policy.

I... couldn't.

I'd read about it. I'd used it. I could spell "LRU cache." But I didn't actually understand how it worked.

I'd been the chauffeur.

So I shut up, went back, actually learned it, then came back to the conversation. It was humbling. It was also necessary.

The Point Isn't Perfection

You don't need to understand everything from first principles. That's impossible.

The point is recognizing when you're operating on chauffeur knowledge versus real understanding - and being honest about which one you have.

Sometimes chauffeur knowledge is fine. If you're prototyping fast, copy that Stack Overflow solution. Ship it. Learn later.

But when you're building something that matters - something people depend on, something that needs to scale, something you'll maintain for years - that's when you need to slow down and actually understand what you're doing.

One Last Thing

If you made it this far and thought, "Oh god, this is me" - good.

That means you're self-aware enough to do something about it.

The worst developers I've worked with weren't the ones with chauffeur knowledge. They were the ones who refused to admit it.

The best developers I've worked with? They said "I don't know" constantly. Then they'd go learn, come back, and teach the rest of us.

Be the second kind.

P.S. - If you're reading this thinking "I should share this in Slack," but worried your team will think you're calling them out... you're overthinking it. Share it anyway. The developers who need it most won't realize it's about them. The ones who do realize are already working on it.

Entity framework core

Korir Moses — Fri, 04 Jul 2025 11:04:04 +0000

Korir Moses

Jul 4 '25

Entity Framework Race Conditions: The Silent Data Corruption Bug - And How to Fix It

#webdev #programming #csharp #sql

Comments 1

7 min read

Entity Framework Race Conditions: The Silent Data Corruption Bug - And How to Fix It

Korir Moses — Fri, 04 Jul 2025 11:03:30 +0000

When Performance Optimizations Become Data Disasters
Race conditions in Entity Framework applications are among the most dangerous bugs you'll encounter in production systems. They're invisible during development, pass all unit tests, and only surface under real-world load conditions. When they do appear, they can cause data corruption, duplicate processing, and system-wide inconsistencies that are expensive to fix.
This article explores the anatomy of EF race conditions, demonstrates how they manifest in production, and provides proven solutions to prevent them.
The Anatomy of a Race Condition
The Perfect Storm: Three Ingredients for Disaster
Entity Framework race conditions typically require three conditions to manifest:

Change Tracking Disabled: Using .AsNoTracking() on entities you plan to modify
Concurrent Access: Multiple threads or processes accessing the same data
State Modification: Attempting to update entity state without proper tracking Let's examine a typical scenario with a background job processing system:

// ❌ DANGEROUS: This code contains a race condition
public class OrderProcessingService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public async Task ProcessPendingOrdersAsync()
    {
        var pendingOrders = await GetPendingOrdersAsync();

        while (pendingOrders.Any())
        {
            await ProcessOrderBatchAsync(pendingOrders);
            // Race condition: Next batch retrieved before previous updates are committed
            pendingOrders = await GetPendingOrdersAsync();
        }
    }

    private async Task<List<Order>> GetPendingOrdersAsync()
    {
        using var scope = _scopeFactory.CreateScope();
        var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

        var orders = await context.Orders
            .Where(o => o.Status == OrderStatus.Pending)
            .Take(10)
            .AsNoTracking() // ❌ PROBLEM: Disables change tracking
            .ToListAsync();

        // ❌ PROBLEM: These changes are invisible to EF
        foreach (var order in orders)
        {
            order.Status = OrderStatus.Processing;
            order.LastModified = DateTime.UtcNow;
        }

        if (orders.Any())
        {
            // ❌ PROBLEM: SaveChanges does nothing - no tracked changes
            await context.SaveChangesAsync();
        }

        return orders;
    }

    private async Task ProcessOrderBatchAsync(List<Order> orders)
    {
        var tasks = orders.Select(ProcessSingleOrderAsync);
        await Task.WhenAll(tasks);
    }

    private async Task ProcessSingleOrderAsync(Order order)
    {
        using var scope = _scopeFactory.CreateScope();
        var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

        try
        {
            // Process the order (call external APIs, etc.)
            await ProcessOrderExternally(order);

            order.Status = OrderStatus.Completed;
            order.CompletedAt = DateTime.UtcNow;

            // Update in database
            context.Orders.Attach(order);
            context.Entry(order).State = EntityState.Modified;
            await context.SaveChangesAsync();
        }
        catch (Exception ex)
        {
            order.Status = OrderStatus.Failed;
            order.ErrorMessage = ex.Message;

            context.Orders.Attach(order);
            context.Entry(order).State = EntityState.Modified;
            await context.SaveChangesAsync();
        }
    }
}

The Production Nightmare: What Actually Happens
In production, this code creates a devastating race condition:

Timeline of Disaster:
T1: Worker A: GetPendingOrders() → Returns [Order 1001, 1002, 1003]
T2: Worker A: Sets status to Processing → NOT SAVED (AsNoTracking)
T3: Worker B: GetPendingOrders() → Returns [Order 1001, 1002, 1003] AGAIN!
T4: Worker A: ProcessOrderBatch() → Processes orders
T5: Worker B: ProcessOrderBatch() → Processes SAME orders again
T6: Duplicate processing, double charges, data corruption

The Debugging Challenge
The race condition is nearly impossible to reproduce in development because:

Low Latency: Local databases respond instantly
Single Process: Development typically runs one instance
Low Concurrency: Limited concurrent operations
Different Connection Pooling: Production pools behave differently
Real-World Impact Assessment
E-commerce Systems
Duplicate Orders: Customers charged multiple times
Inventory Issues: Stock levels become incorrect
Shipping Problems: Multiple shipments for single orders
Financial Applications
Double Transactions: Money transferred multiple times
Account Imbalances: Incorrect balance calculations
Reconciliation Failures: Mismatched records across systems
Content Management Systems
Duplicate Content: Articles published multiple times
Workflow Corruption: Approval processes broken
Audit Trail Issues: Incomplete change tracking
The Fix: Proven Solutions
Solution 1: Remove AsNoTracking (Immediate Fix)

// ✅ FIXED: Enable change tracking for entities we plan to modify
private async Task<List<Order>> GetPendingOrdersAsync()
{
    using var scope = _scopeFactory.CreateScope();
    var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    var orders = await context.Orders
        .Where(o => o.Status == OrderStatus.Pending)
        .Take(10)
        // ✅ REMOVED: .AsNoTracking()
        .ToListAsync();

    // ✅ FIXED: Changes are now tracked
    foreach (var order in orders)
    {
        order.Status = OrderStatus.Processing;
        order.LastModified = DateTime.UtcNow;
    }

    if (orders.Any())
    {
        // ✅ FIXED: SaveChanges now works
        await context.SaveChangesAsync();
    }

    return orders;
}

Solution 2: Atomic Update Pattern (Robust)

// ✅ BEST PRACTICE: Atomic select-and-update operation
private async Task<List<Order>> GetPendingOrdersAsync()
{
    using var scope = _scopeFactory.CreateScope();
    var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    using var transaction = await context.Database.BeginTransactionAsync();

    try
    {
        // Step 1: Select IDs of orders to process
        var orderIds = await context.Orders
            .Where(o => o.Status == OrderStatus.Pending)
            .OrderBy(o => o.CreatedAt)
            .Take(10)
            .Select(o => o.Id)
            .ToListAsync();

        if (!orderIds.Any())
            return new List<Order>();

        // Step 2: Atomically update status
        await context.Orders
            .Where(o => orderIds.Contains(o.Id))
            .ExecuteUpdateAsync(o => o
                .SetProperty(x => x.Status, OrderStatus.Processing)
                .SetProperty(x => x.LastModified, DateTime.UtcNow));

        // Step 3: Retrieve updated orders
        var orders = await context.Orders
            .Where(o => orderIds.Contains(o.Id))
            .ToListAsync();

        await transaction.CommitAsync();
        return orders;
    }
    catch
    {
        await transaction.RollbackAsync();
        throw;
    }
}

Solution 3: Database-Level Locking (Advanced)

// ✅ ADVANCED: Use database row locking for absolute safety
private async Task<List<Order>> GetPendingOrdersAsync()
{
    using var scope = _scopeFactory.CreateScope();
    var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    // Use raw SQL with row locking
    var sql = @"
        UPDATE TOP(@batchSize) Orders 
        SET Status = @processingStatus, LastModified = @now
        OUTPUT INSERTED.*
        WHERE Status = @pendingStatus
        ORDER BY CreatedAt";

    var parameters = new[]
    {
        new SqlParameter("@batchSize", 10),
        new SqlParameter("@processingStatus", (int)OrderStatus.Processing),
        new SqlParameter("@pendingStatus", (int)OrderStatus.Pending),
        new SqlParameter("@now", DateTime.UtcNow)
    };

    var orders = await context.Orders
        .FromSqlRaw(sql, parameters)
        .ToListAsync();

    return orders;
}

Solution 4: Distributed Locking (Microservices)

// ✅ MICROSERVICES: Use distributed locking
public class OrderProcessingService
{
    private readonly IDistributedLock _distributedLock;

    public async Task ProcessPendingOrdersAsync()
    {
        var lockKey = "order-processing-lock";
        var lockExpiry = TimeSpan.FromMinutes(5);

        await using var @lock = await _distributedLock.AcquireAsync(lockKey, lockExpiry);

        if (@lock == null)
        {
            _logger.LogInformation("Another instance is processing orders");
            return;
        }

        var pendingOrders = await GetPendingOrdersAsync();

        while (pendingOrders.Any())
        {
            await ProcessOrderBatchAsync(pendingOrders);
            pendingOrders = await GetPendingOrdersAsync();
        }
    }
}

Performance Considerations
When to Use AsNoTracking
AsNoTracking is safe and beneficial for:

// ✅ SAFE: Read-only operations
public async Task<List<OrderSummary>> GetOrderSummariesAsync()
{
    return await _context.Orders
        .Where(o => o.Status == OrderStatus.Completed)
        .Select(o => new OrderSummary
        {
            Id = o.Id,
            CustomerName = o.Customer.Name,
            Total = o.Total
        })
        .AsNoTracking() // ✅ Safe - we're not modifying entities
        .ToListAsync();
}

// ✅ SAFE: Reporting and analytics
public async Task<decimal> GetMonthlyRevenueAsync()
{
    return await _context.Orders
        .Where(o => o.CreatedAt.Month == DateTime.Now.Month)
        .AsNoTracking() // ✅ Safe - aggregate operation
        .SumAsync(o => o.Total);
}

Performance Optimization Strategies

// ✅ OPTIMIZED: Use projection for read-only data
public async Task<List<OrderListItem>> GetOrdersForDisplayAsync()
{
    return await _context.Orders
        .Select(o => new OrderListItem
        {
            Id = o.Id,
            CustomerName = o.Customer.Name,
            Status = o.Status,
            Total = o.Total
        })
        .AsNoTracking() // ✅ Safe - projected data
        .ToListAsync();
}

// ✅ OPTIMIZED: Split reads and writes
public async Task ProcessOrdersAsync()
{
    // Read-only query for IDs
    var orderIds = await _context.Orders
        .Where(o => o.Status == OrderStatus.Pending)
        .Select(o => o.Id)
        .AsNoTracking() // ✅ Safe - just IDs
        .ToListAsync();

    // Separate tracked query for updates
    var orders = await _context.Orders
        .Where(o => orderIds.Contains(o.Id))
        .ToListAsync(); // ✅ Tracked for updates

    foreach (var order in orders)
    {
        order.Status = OrderStatus.Processing;
    }

    await _context.SaveChangesAsync();
}

Testing Strategies
Unit Tests for Race Conditions

[Test]
public async Task ProcessOrders_WithConcurrentWorkers_ShouldNotProcessSameOrderTwice()
{
    // Arrange
    var orders = CreateTestOrders(20);
    await SeedDatabase(orders);

    // Act: Start multiple workers concurrently
    var tasks = Enumerable.Range(0, 5)
        .Select(_ => _orderService.ProcessPendingOrdersAsync())
        .ToArray();

    await Task.WhenAll(tasks);

    // Assert: No order should be processed twice
    var processedOrders = await GetProcessedOrders();
    var duplicates = processedOrders
        .GroupBy(o => o.Id)
        .Where(g => g.Count() > 1)
        .ToList();

    Assert.That(duplicates, Is.Empty, 
        $"Found duplicate processing for orders: {string.Join(",", duplicates.Select(g => g.Key))}");
}

Integration Tests with Database

[Test]
public async Task ProcessOrders_UnderLoad_ShouldMaintainDataIntegrity()
{
    // Arrange
    var orderCount = 100;
    var workerCount = 10;
    var orders = CreateTestOrders(orderCount);
    await SeedDatabase(orders);

    // Act: Simulate production load
    var workers = Enumerable.Range(0, workerCount)
        .Select(async _ =>
        {
            for (int i = 0; i < 5; i++)
            {
                await _orderService.ProcessPendingOrdersAsync();
                await Task.Delay(100); // Simulate processing time
            }
        })
        .ToArray();

    await Task.WhenAll(workers);

    // Assert: Verify data integrity
    var allOrders = await _context.Orders.ToListAsync();

    // No order should be stuck in Processing status
    var stuckOrders = allOrders
        .Where(o => o.Status == OrderStatus.Processing)
        .ToList();
    Assert.That(stuckOrders, Is.Empty);

    // All orders should be either Completed or Failed
    var finalStates = allOrders
        .Where(o => o.Status == OrderStatus.Completed || o.Status == OrderStatus.Failed)
        .ToList();
    Assert.That(finalStates.Count, Is.EqualTo(orderCount));
}

Monitoring and Alerting
Key Metrics to Track

public class OrderProcessingMetrics
{
    private readonly IMetricsLogger _metrics;

    public async Task TrackProcessingMetrics()
    {
        // Track stuck orders
        var stuckOrders = await _context.Orders
            .Where(o => o.Status == OrderStatus.Processing && 
                       o.LastModified < DateTime.UtcNow.AddMinutes(-10))
            .CountAsync();

        _metrics.Gauge("orders.stuck_in_processing", stuckOrders);

        // Track duplicate processing attempts
        var duplicateProcessingAttempts = await _context.OrderProcessingLogs
            .Where(l => l.CreatedAt > DateTime.UtcNow.AddMinutes(-5))
            .GroupBy(l => l.OrderId)
            .Where(g => g.Count() > 1)
            .CountAsync();

        _metrics.Gauge("orders.duplicate_processing_attempts", duplicateProcessingAttempts);

        // Track processing rate
        var processingRate = await _context.Orders
            .Where(o => o.Status == OrderStatus.Processing)
            .CountAsync();

        _metrics.Gauge("orders.current_processing_rate", processingRate);
    }
}

Alert Conditions

public class OrderProcessingAlerts
{
    public async Task CheckForAnomalies()
    {
        // Alert: Too many orders stuck in processing
        var stuckCount = await GetStuckOrdersCount();
        if (stuckCount > 50)
        {
            await SendAlert("High number of stuck orders detected", 
                $"Found {stuckCount} orders stuck in processing status");
        }

        // Alert: Duplicate processing detected
        var duplicateCount = await GetDuplicateProcessingCount();
        if (duplicateCount > 0)
        {
            await SendAlert("Duplicate order processing detected", 
                $"Found {duplicateCount} orders processed multiple times");
        }

        // Alert: Processing rate anomaly
        var processingRate = await GetCurrentProcessingRate();
        var historicalAverage = await GetHistoricalProcessingRate();

        if (processingRate > historicalAverage * 2)
        {
            await SendAlert("Unusual processing rate detected", 
                $"Current rate: {processingRate}, Average: {historicalAverage}");
        }
    }
}

Prevention Checklist
Code Review Guidelines

Change Tracking: Are we using AsNoTracking() on entities we plan to modify?
Concurrency: Could multiple workers process the same data?
Atomicity: Are related operations wrapped in transactions?
State Management: Are entity states properly managed across scopes?
Error Handling: Do we handle partial failures correctly? Architecture Patterns
Single Responsibility: Each service has clear ownership of data
Idempotency: Operations can be safely repeated
Optimistic Concurrency: Use row versions for conflict detection
Event Sourcing: Consider event-driven architectures for complex workflows
CQRS: Separate read and write models where appropriate Conclusion Entity Framework race conditions are silent killers in production applications. They manifest only under realistic load conditions and can cause significant data corruption before being detected. The key to prevention is understanding when and why to use performance optimizations like AsNoTracking(). Key Takeaways
Never use AsNoTracking() on entities you plan to modify
Use atomic operations for critical state changes
Test with realistic concurrent scenarios
Monitor for stuck entities and duplicate processing
Implement proper error handling and rollback strategies When in Doubt, Choose Safety In production systems, data integrity is more important than marginal performance gains. It's better to have slightly slower but correct operations than fast operations that corrupt your data. Remember: The most expensive bugs are the ones that silently corrupt data over time. Invest in proper testing, monitoring, and defensive programming practices to prevent race conditions from reaching production. The cost of fixing data corruption far exceeds the cost of preventing it in the first place.

Advanced Performance Optimization: Using Dotnet Channels

Korir Moses — Mon, 02 Jun 2025 07:06:40 +0000

Summary
In the rapidly evolving landscape of mobile financial services and telecommunications applications, USSD (Unstructured Supplementary Service Data) remains a critical channel for delivering services to users across diverse network conditions. However, the inherent constraints of USSD—including session timeouts, synchronous communication patterns, and limited bandwidth—present unique challenges for developers seeking to deliver responsive, data-rich applications.
This article explores the implementation of fire-and-forget background processing patterns in USSD applications, demonstrating how asynchronous data fetching can dramatically improve user experience while maintaining system reliability and performance. We'll examine real-world implementation strategies, performance considerations, and best practices for enterprise-grade USSD applications.
The USSD Performance Challenge
Understanding USSD Constraints
USSD applications operate within a constrained environment that demands careful architectural consideration:
Session Timeout Limitations, USSD sessions typically expire within 30-180 seconds, depending on the mobile network operator
Synchronous Communication Model, Each user interaction requires an immediate response
Network Latency Variability, Response times can vary significantly based on network conditions
Memory Constraints, Limited session state management capabilities
Sequential Processing, Users must wait for each operation to complete before proceeding
Traditional Synchronous Approach Limitations
In conventional USSD implementations, data fetching operations block the user interface flow:

// Traditional blocking approach
public async Task<UssdResponse> HandleLoginAsync(string msisdn, string pin)
{
    // Authenticate user
    var user = await _authService.ValidateUserAsync(msisdn, pin);

    // Blocking operations that delay response
    var banks = await _bankService.GetSupportedBanksAsync();
    var accounts = await _accountService.GetUserAccountsAsync(msisdn);
    var transactions = await _transactionService.GetRecentTransactionsAsync(msisdn);

    // User waits for all operations to complete
    return UssdResponse.Continue("Welcome! Select an option...");
}

This approach introduces several critical issues:

Increased Response Times: Users experience delays while waiting for multiple API calls
Higher Timeout Risk: Extended processing time increases session timeout probability 3.Poor User Experience: Perceived application sluggishness reduces user satisfaction 4.Resource Inefficiency: Blocking threads waste computational resources Fire-and-Forget: A Modern Solution Architectural Overview Fire-and-forget background processing addresses these limitations by decoupling data fetching from user interface flow. The pattern involves: 1.Immediate Response: Return control to the user immediately after essential operations 2.Background Processing: Execute data fetching operations asynchronously 3.Intelligent Caching: Store fetched data for future use 4.Graceful Fallback: Handle scenarios where background data isn't yet available Implementation Architecture The core fire-and-forget helper provides controlled background execution

public void Run(Func<IServiceProvider, Task> operation)
{
    Task.Run(async () => 
    {
        await _concurrencyLimiter.WaitAsync(); // Prevent resource exhaustion
        try
        {
            using var scope = _scopeFactory.CreateScope();
            await operation(scope.ServiceProvider);
        }
        catch (Exception ex) { /* Log errors, never crash */ }
        finally { _concurrencyLimiter.Release(); }
    });
}

Enhanced Login Implementation

The login handler separates critical authentication from data fetching:

public async Task<UssdResponse> HandleLoginAsync(string msisdn, string pin)
{
    // Only essential synchronous operations
    var user = await _authService.ValidateUserAsync(msisdn, pin);
    if (user == null) return UssdResponse.End("Invalid credentials");

    // Start background loading immediately
    InitiateBackgroundDataLoading(msisdn);

    // Return control to user without waiting
    return UssdResponse.Continue($"Welcome {user.Name}!\n1. Account Services\n2. Transfer Money");
}
The background loading handles multiple services with timeout protection
_fireAndForgetHelper.Run(async sp =>
{
    using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(45));

    await Task.WhenAll(
        LoadAndCacheBanks(bankService, cache, cts.Token),
        LoadAndCacheUserAccounts(accountService, msisdn, cache, cts.Token)
    );

    // Signal completion for later states
    await cache.SetStringAsync($"data_ready_{msisdn}", "true", expiration);
});
## Advanced Caching Strategies

### Hierarchical Caching Implementation

A multi-layer cache approach optimizes data access patterns:

csharp
// Check memory cache first (fastest)
if (_memoryCache.TryGetValue(key, out T cachedValue))
return cachedValue;

// Check distributed cache (Redis/SQL)
var distributedValue = await _distributedCache.GetStringAsync(key);
if (distributedValue != null)
{
var data = JsonSerializer.Deserialize(distributedValue);
_memoryCache.Set(key, data, TimeSpan.FromMinutes(5)); // Populate memory cache
return data;
}

// Fetch from source and populate both caches
var freshValue = await factory();
await StoreInBothCaches(key, freshValue);
Best Practices and Recommendations
** 1.Resource Management**
Connection Pooling: Implement proper database and HTTP connection pooling to prevent resource exhaustion
Thread Pool Management: Monitor thread pool usage and implement semaphores to limit concurrent background operations
Memory Management: Implement cache size limits and automatic cleanup for user-specific data
2. Monitoring and Observability
Performance Metrics: Track response times, cache hit rates, and background task completion rates
Error Tracking: Implement comprehensive error logging with correlation IDs for debugging
Health Checks: Monitor the health of background services and dependent systems
3.Configuration Management

public class UssdConfiguration
{
    public TimeSpan BackgroundTaskTimeout { get; set; } = TimeSpan.FromSeconds(45);
    public int MaxConcurrentBackgroundTasks { get; set; } = 10;
    public TimeSpan CacheExpirationTime { get; set; } = TimeSpan.FromMinutes(15);
    public int CircuitBreakerFailureThreshold { get; set; } = 5;
    public TimeSpan CircuitBreakerTimeout { get; set; } = TimeSpan.FromMinutes(2);
    public bool EnableAggressiveCaching { get; set; } = true;
}

4.Testing Strategies
Load Testing: Simulate high concurrent user loads to validate background processing performance
Chaos Engineering: Test system resilience by introducing controlled failures
Cache Testing: Verify cache invalidation and refresh mechanisms work correctly
Conclusion
Fire-and-forget background processing represents a paradigm shift in USSD application architecture, enabling developers to deliver responsive user experiences while maintaining robust data access capabilities. The pattern's success lies in its ability to decouple user interface flow from data fetching operations, leveraging asynchronous processing and intelligent caching to create seamless user experiences.
As mobile financial services continue to evolve and user expectations increase, implementing sophisticated background processing patterns becomes not just an optimization but a necessity for competitive advantage. Organizations that embrace these architectural patterns will be better positioned to deliver the fast, reliable services that modern users demand

Clean Architecture in .NET: Moving Beyond Generic Repositories and Leveraging IServiceScopeFactory

Korir Moses — Wed, 28 May 2025 06:09:25 +0000

Abstract
In modern software development, architectural patterns such as Domain-Driven Design (DDD), Clean Architecture, and Command Query Responsibility Segregation (CQRS) have gained widespread adoption. However, their implementation often leads to over-engineering through unnecessary abstractions like generic IRepository interfaces. This article examines when these patterns add value versus when they introduce complexity, proposes intent-driven alternatives to generic repositories, and demonstrates the proper application of IServiceScopeFactory for managing service lifetimes in .NET applications.
Introduction
The pursuit of "good architecture" has led many development teams to adopt heavyweight patterns and abstractions without sufficient consideration of their actual requirements. While patterns like Clean Architecture provide valuable guidance, their mechanical application often results in code that is more complex than necessary. This analysis focuses on identifying when architectural patterns serve genuine needs versus when they constitute over-engineering.
Clean Architecture: Principles and Pragmatism
Clean Architecture, as articulated by Robert C. Martin, establishes a layered approach to software design with clear separation of concerns:
Core Layers:

Entities: Domain models containing business rules, isolated from infrastructure concerns
Use Cases: Application services orchestrating business workflows
Interface Adapters: Translation layer between domain and external systems
Infrastructure: Databases, web frameworks, and external services

The fundamental principle—the Dependency Rule—ensures that business logic remains independent of infrastructure decisions, enhancing testability and maintainability.
The Context-Dependent Nature of Architectural Patterns
When DDD and CQRS Add Value:

Complex business domains requiring sophisticated modeling
Systems with distinct read/write optimization needs
Applications where domain expertise is critical to success
Large teams requiring shared understanding through ubiquitous language

When They Become Overhead:

CRUD-centric applications with straightforward business rules
Small teams lacking domain modeling expertise
Tight delivery timelines where complexity impedes progress
Domains that don't justify the learning curve and maintenance overhead

The key insight is that architectural patterns should solve actual problems, not theoretical ones.
The Generic Repository Anti-Pattern
The IRepository interface represents a common abstraction that appears beneficial but often creates more problems than it solves:

public interface IRepository<T>
{
    T GetById(Guid id);
    void Add(T entity);
    void Delete(T entity);
    IEnumerable<T> GetAll();
}

Critical Limitations
1. Semantic Mismatch with Domain Operations
Business operations rarely align with generic CRUD operations. Consider an e-commerce scenario:

Retrieving orders may require specific filtering by status, customer, or date range
Order updates might be restricted based on fulfillment status
Deletion might be prohibited for auditing reasons

Generic repositories cannot express these domain-specific constraints effectively.
2. Abstraction Leakage
Many implementations expose IQueryable, creating tight coupling between domain logic and ORM-specific constructs. This coupling:

Makes unit testing more complex
Prevents clean separation between layers
Reduces flexibility in data access strategy changes
**

Promotion of Anemic Domain Models** By externalizing all data access logic, generic repositories encourage treating domain entities as mere data containers, violating object-oriented principles and reducing code expressiveness. Intent-Driven Repository Design A superior approach involves creating repositories that reflect actual business operations:

public interface IOrderRepository
{
    Task<Order?> GetPendingOrderForCustomerAsync(Guid customerId);
    Task<IEnumerable<Order>> GetOrdersByStatusAsync(OrderStatus status);
    Task AddAsync(Order order);
    Task<bool> CanCancelOrderAsync(Guid orderId);
}

Benefits of Intent-Driven Design
Enhanced Clarity: Method names communicate business intent clearly
Better Encapsulation: Implementation details remain hidden
Improved Testability: Mock objects can simulate specific business scenarios
Domain Alignment: Interfaces reflect real-world operations
Refactoring Example
Before (Generic Approach):

public class OrderService
{
    private readonly IRepository<Order> _orderRepository;

    public async Task<IEnumerable<Order>> GetCustomerOrders(Guid customerId)
    {
        var allOrders = await _orderRepository.GetAll();
        return allOrders.Where(o => o.CustomerId == customerId);
    }
}

After (Intent-Driven Approach):

public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public Task<IEnumerable<Order>> GetCustomerOrders(Guid customerId)
    {
        return _orderRepository.GetOrdersByCustomerIdAsync(customerId);
    }
}

The refactored version moves filtering logic into the repository where it belongs, making the service more focused and the abstraction more meaningful.
Understanding IServiceScopeFactory in .NET
While generic repositories often represent unnecessary abstraction, IServiceScopeFactory serves a legitimate architectural purpose in .NET's dependency injection system.
The Service Lifetime Challenge
.NET Core supports three service lifetimes:

Singleton: Created once per application
Scoped: Created once per HTTP request
Transient: Created each time requested

Problems arise when singleton services need to consume scoped services (like DbContext) outside of HTTP request contexts, such as in background services or hosted workers.
IServiceScopeFactory Solution
IServiceScopeFactory enables manual creation of service scopes, allowing safe resolution of scoped services in non-request contexts:

public class OrderProcessingBackgroundService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;
    private readonly ILogger<OrderProcessingBackgroundService> _logger;

    public OrderProcessingBackgroundService(
        IServiceScopeFactory scopeFactory,
        ILogger<OrderProcessingBackgroundService> logger)
    {
        _scopeFactory = scopeFactory;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            using var scope = _scopeFactory.CreateScope();
            var orderService = scope.ServiceProvider.GetRequiredService<IOrderService>();
            var dbContext = scope.ServiceProvider.GetRequiredService<OrderDbContext>();

            try
            {
                await ProcessPendingOrders(orderService, dbContext);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error processing orders");
            }

            await Task.Delay(TimeSpan.FromMinutes(5), stoppingToken);
        }
    }

    private async Task ProcessPendingOrders(IOrderService orderService, OrderDbContext dbContext)
    {
        // Business logic implementation
        var pendingOrders = await orderService.GetPendingOrdersAsync();
        foreach (var order in pendingOrders)
        {
            await orderService.ProcessOrderAsync(order.Id);
        }

        await dbContext.SaveChangesAsync();
    }
}

This approach maintains proper service lifetimes while enabling background processing capabilities.
Implementation Recommendations
1. Start Simple
Begin with straightforward service classes and add abstractions only when genuine needs emerge. Premature abstraction often creates more problems than it solves.
2. Focus on Intent
When creating interfaces, ensure they reflect actual business operations rather than technical CRUD operations.
3. Respect Service Lifetimes
Use IServiceScopeFactory appropriately when consuming scoped services outside HTTP request contexts.

Iterative Refinement Allow architecture to evolve with understanding. What starts as a simple service can be refactored into more sophisticated patterns as complexity justifies the investment. 5. Team Capability Alignment Ensure architectural choices align with team expertise and project timelines. Complex patterns require corresponding knowledge and maintenance commitment. Conclusion Effective software architecture balances structure with pragmatism. While Clean Architecture principles provide valuable guidance, their implementation should be tailored to actual requirements rather than theoretical ideals. Generic repositories often represent over-abstraction, while intent-driven interfaces better serve domain needs. Meanwhile, IServiceScopeFactory addresses legitimate technical requirements in .NET applications. The goal remains constant: creating maintainable, testable, and comprehensible code. This is achieved through thoughtful application of patterns rather than their mechanical adoption. By understanding when patterns add value versus when they introduce unnecessary complexity, development teams can make informed architectural decisions that serve both immediate needs and long-term maintainability. References and Further Reading

Martin, Robert C. "Clean Architecture: A Craftsman's Guide to Software Structure and Design"
Evans, Eric. "Domain-Driven Design: Tackling Complexity in the Heart of Software"
Microsoft Documentation: "Dependency injection in .NET"
Fowler, Martin. "Patterns of Enterprise Application Architecture"

Parameter Perfection: Mastering Positional and Named Arguments in Modern .NET

Korir Moses — Sun, 06 Apr 2025 07:18:23 +0000

Introduction
In the .NET ecosystem, method and constructor parameters serve as the cornerstone for passing data between components. The framework supports two primary parameter passing mechanisms: positional parameters and named parameters. Understanding these concepts in depth is essential for developers to write elegant, maintainable, and error-resistant code. This article explores both approaches in detail, including their syntax, benefits, limitations, and best practices, with a special focus on how they integrate with modern .NET development patterns like Dependency Injection.
Positional Parameters in Depth
Positional parameters represent the traditional approach to parameter passing in most programming languages, including C#. Arguments must be provided in the exact sequence defined in the method or constructor signature.
Basic Syntax and Usage

public class UserProfile
{
    public void UpdateProfile(string username, string email, int age, bool isActive)
    {
        // Implementation
    }
}

// Usage with positional parameters
var profile = new UserProfile();
profile.UpdateProfile("johndoe", "john@example.com", 32, true);

Advanced Scenarios with Positional Parameters
Method Overloading
Positional parameters work seamlessly with method overloading, allowing multiple method implementations with different parameter types or counts:

public class MessageFormatter
{
    public string Format(string message)
    {
        return $"INFO: {message}";
    }

    public string Format(string message, bool isError)
    {
        return isError ? $"ERROR: {message}" : $"INFO: {message}";
    }

    public string Format(string message, string category, int priority)
    {
        return $"{category}({priority}): {message}";
    }
}

Parameter Arrays (params)
The params keyword allows methods to accept a variable number of arguments:

public class Calculator
{
    public int Sum(params int[] numbers)
    {
        int result = 0;
        foreach (var num in numbers)
        {
            result += num;
        }
        return result;
    }
}

// Usage
var calc = new Calculator();
int result1 = calc.Sum(1, 2, 3);        // Passes 3 arguments
int result2 = calc.Sum(10, 20, 30, 40); // Passes 4 arguments

Limitations of Positional Parameters

Cognitive Load: When dealing with methods that have numerous parameters, remembering the correct order becomes challenging.
Error Proneness: Passing arguments in the wrong order can lead to runtime errors, especially when multiple parameters share the same type.
Code Readability: Without looking at the method definition, it might be difficult to understand what each argument represents.
Maintenance Challenges: Adding, removing, or reordering parameters in a method signature can break existing code that relies on positional arguments.

Named Parameters in Depth
Named parameters allow developers to specify arguments by parameter name rather than position, offering greater flexibility and clarity.
Basic Syntax and Usage

public class NotificationService
{
    public void SendNotification(string recipient, string subject, string body, bool isUrgent = false, string[] attachments = null)
    {
        // Implementation
    }
}

// Usage with named parameters
var notifier = new NotificationService();
notifier.SendNotification(
    recipient: "user@example.com",
    subject: "Meeting Reminder",
    body: "Don't forget our meeting tomorrow",
    isUrgent: true
);

Advanced Scenarios with Named Parameters
Optional Parameters with Default Values
Named parameters work exceptionally well with optional parameters that have default values:

public class ReportGenerator
{
    public string GenerateReport(
        string title,
        DateTime startDate,
        DateTime endDate,
        bool includeCharts = true,
        string format = "PDF",
        int compressionLevel = 0,
        bool encrypt = false
    )
    {
        // Implementation
        return $"Report generated: {title} ({format})";
    }
}

// Usage examples
var generator = new ReportGenerator();

// Only providing required parameters, using defaults for the rest
string report1 = generator.GenerateReport(
    title: "Sales Report",
    startDate: new DateTime(2023, 1, 1),
    endDate: new DateTime(2023, 3, 31)
);

// Providing required parameters and selectively overriding some defaults
string report2 = generator.GenerateReport(
    title: "Financial Analysis",
    startDate: new DateTime(2023, 1, 1),
    endDate: new DateTime(2023, 12, 31),
    format: "Excel",
    encrypt: true
);

Using Named Arguments with Delegates and Lambda Expressions
Named parameters can enhance clarity when working with delegates and lambda expressions:

public class UserManager
{
    public List<User> FilterUsers(List<User> users, Func<User, bool> predicate)
    {
        return users.Where(predicate).ToList();
    }
}

var manager = new UserManager();
var filteredUsers = manager.FilterUsers(
    users: allUsers,
    predicate: user => user.Age > 18 && user.IsActive
);

Leading Named Arguments
Named arguments can be followed by positional arguments, as long as all positional arguments are in the correct position:

public void ConfigureService(string name, int timeout, bool isEnabled)
{
    // Implementation
}

// Valid in C# 7.2 and later
ConfigureService(name: "AuthService", 30, isEnabled: true);

Combining Positional and Named Parameters
In practice, a hybrid approach often offers the best balance between conciseness and clarity.
Best Practices for Combining Both Approaches

Use positional parameters for mandatory, logically ordered arguments:

public void ScheduleAppointment(DateTime dateTime, string patientName, bool isEmergency = false)
{
    // Implementation
}

// Usage
ScheduleAppointment(DateTime.Now.AddDays(1), "John Smith", isEmergency: true);

Use named parameters for boolean flags and optional parameters:

public void ProcessOrder(string orderId, double amount, string currency = "USD", bool expediteShipping = false)
{
    // Implementation
}

// Usage
ProcessOrder("ORD-12345", 299.99, expediteShipping: true);

Parameter Passing in Dependency Injection
Dependency Injection (DI) is a design pattern that has become the standard approach for managing dependencies in .NET applications, especially with ASP.NET Core.
Constructor Injection
Constructor injection is the most common form of DI in .NET. When a class is resolved from the DI container, its constructor parameters are automatically provided:

public class OrderService
{
    private readonly IRepository<Order> _orderRepository;
    private readonly IPaymentProcessor _paymentProcessor;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IRepository<Order> orderRepository,
        IPaymentProcessor paymentProcessor,
        ILogger<OrderService> logger)
    {
        _orderRepository = orderRepository;
        _paymentProcessor = paymentProcessor;
        _logger = logger;
    }

    // Service methods
}

Registration Examples with the Built-in DI Container

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // Register dependencies
        services.AddScoped<IRepository<Order>, OrderRepository>();
        services.AddSingleton<IPaymentProcessor, StripePaymentProcessor>();
        services.AddTransient<OrderService>();

        // Register with factory method and named parameters
        services.AddSingleton<IConfigurationService>(sp => new ConfigurationService(
            environment: "Production",
            useCache: true,
            logger: sp.GetRequiredService<ILogger<ConfigurationService>>()
        ));
    }
}

Advantages in Testing Scenarios
Named parameters significantly improve the readability of test setup code:

[Fact]
public void ProcessOrder_ValidOrder_ReturnsOrderConfirmation()
{
    // Arrange
    var mockRepository = new Mock<IRepository<Order>>();
    var mockProcessor = new Mock<IPaymentProcessor>();
    var mockLogger = new Mock<ILogger<OrderService>>();

    var orderService = new OrderService(
        orderRepository: mockRepository.Object,
        paymentProcessor: mockProcessor.Object,
        logger: mockLogger.Object
    );

    var testOrder = new Order { /* Test data */ };

    // Act
    var result = orderService.ProcessOrder(testOrder);

    // Assert
    Assert.NotNull(result);
    Assert.Equal("Confirmed", result.Status);
}

Advanced Parameter Patterns in Modern .NET
Record Types and Positional Parameters (C# 9.0+)
C# 9.0 introduced record types with positional parameters for immutable data models:

// Record with positional parameters
public record Person(string FirstName, string LastName, int Age);

// Usage
var person = new Person("John", "Doe", 30);

// Deconstruction
var (firstName, lastName, age) = person;

Options Pattern for Complex Configurations
The Options Pattern is commonly used in ASP.NET Core for handling complex configurations:

public class SmtpOptions
{
    public string Server { get; set; }
    public int Port { get; set; }
    public bool UseSsl { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
}

public class EmailService
{
    private readonly SmtpOptions _options;

    public EmailService(IOptions<SmtpOptions> options)
    {
        _options = options.Value;
    }

    // Service methods
}

// Registration
services.Configure<SmtpOptions>(configuration.GetSection("Smtp"));

Extension Methods and Fluent APIs
Extension methods often use named parameters to enhance readability in fluent APIs

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddCustomAuthentication(
        this IServiceCollection services,
        string authority = null,
        bool requireHttpsMetadata = true,
        string apiName = null,
        string apiSecret = null)
    {
        // Implementation
        return services;
    }
}

// Usage
services.AddCustomAuthentication(
    authority: "https://auth.example.com",
    apiName: "api1",
    requireHttpsMetadata: false
);

Conclusion
Positional and named parameters each offer distinct advantages in .NET development. Positional parameters provide conciseness and efficiency for simple method signatures, while named parameters enhance code readability, maintainability, and self-documentation for complex APIs.
Modern .NET development often employs a hybridized approach, using positional parameters for straightforward, commonly-used methods and named parameters for complex configurations, optional parameters, and in scenarios where code clarity is paramount. This balanced approach results in code that is both efficient and maintainable.
As .NET continues to evolve, understanding the nuances of parameter passing becomes increasingly important, especially in the context of cross-platform development, microservices architectures, and cloud-native applications where clear, maintainable code is essential for long-term project success.
By following the guidelines and best practices outlined in this article, developers can make informed decisions about parameter usage, leading to more robust, readable, and maintainable .NET applications.

Building a Scalable USSD Banking Solution for a Bank

Korir Moses — Sun, 23 Mar 2025 09:05:51 +0000

Introduction
In the bustling financial landscape of Africa, banks are faced with a significant challenge, how to provide reliable, secure banking services across multiple countries where smartphone penetration remains low and internet connectivity unstable. This case study explores how a USSD-based banking solution can transform operations across multiple countries, bringing banking services to thousands without requiring internet access or smartphones.
The African Banking Landscape
Across many African regions, traditional mobile banking applications face substantial barriers:

Low smartphone adoption rates in rural areas
Inconsistent and expensive internet connectivity
Cost prohibitions of mobile data for many customers
Despite these challenges, the demand for accessible banking services continues to grow. USSD (Unstructured Supplementary Service Data) technology offers a compelling alternative, allowing customers to access banking services through any mobile phone by dialing simple code sequences like *123#.
For Banks to achieve more effective solution,
Most Bank with operations spread across Africa, need to consolidate disparate systems from its subsidiaries into a unified platform. Their requirements are clear but demanding:
Create a single, maintainable codebase that could serve multiple countries
Ensure robust security for financial transactions
Deliver near-instant response times within USSD's tight session constraints
Support core banking functions: balance checks, transfers, bill payments, and airtime purchases
Seamlessly integrate with their existing core banking infrastructure

The stakes are always high a system serving thousands of customers needs to be reliable, secure, and fast, all while operating under the technical constraints of USSD technology.
Technical Solution: Architecture for Scale
The solution leverages modern architecture patterns while respecting the limitations of USSD technology:
Technology Foundation

Backend: .NET 8.0 (C#) provided a robust, performance-focused foundation
Database: PostgreSQL offered reliability with flexible data structures
Deployment: Docker containers orchestrated by Kubernetes enabled scalability
Security: JWT authentication and end-to-end encryption protected sensitive data
Caching: Redis managed user sessions, critical for preserving state in USSD's restrictive environment

Microservices Approach
Rather than building a monolithic application, the system can be decomposed into specialized services:

USSD Gateway Service: The first point of contact for all user requests, handling the complexities of the USSD protocol and maintaining session state.
Authentication Service: A dedicated security layer implementing JWT tokens, encryption, and PIN validation, ensuring that every transaction is properly authorized.
Transaction Service: The core banking engine, processing balance inquiries, transfers, payments, and purchases while communicating with the banking core system.
Session Management: A Redis-based caching layer that preserved user context across the short-lived USSD sessions, creating a smoother experience.

The microservices design proves crucial for both development velocity and operational resilience - issues in one component wouldn't cascade to others, and teams could focus on specific aspects of the system.
Key Innovations
Several innovative approaches distinguished this solution:
Dynamic Menu System
Rather than hardcoding USSD menus, the system retrieved menu structures from a database. This seemingly simple choice has profound implications:

Marketing teams could modify customer offerings without developer intervention
Region-specific promotions could be deployed instantly
Menu updates didn't require system redeployment

Multi-Tenancy Architecture
The system should implement a sophisticated multi-tenant design where:

A single codebase serves all the subsidiary countries
Each country operated as a configurable "tenant"
Country-specific banking rules, languages, and services be configured rather than coded
New countries could be onboarded without code changes

USSD Emulator
One particularly valuable innovation was a custom USSD emulator that
Simulates real-world USSD interactions in a developer environment
To Allow comprehensive testing without physical phones, this will
greatly reduce development-test cycles.
Enable automated testing of complex banking flows

Overcoming Technical Challenges
The development journey isn't without significant obstacles:
The Session Timeout Problem
USSD sessions typically timeout after just 2-3 minutes, creating a poor user experience if a transaction is interrupted. The solution:
Implement Redis-based session persistence
Created unique session identifiers tied to phone numbers
Reduced redundant data entry, improving customer satisfaction

Multi-Country Regulatory Compliance
Each country has different banking regulations and compliance requirements. To address this:

Designed a rule-based configuration system
Create country-specific validation rules without code changes
Implement an audit trail for regulatory reporting
Enable per-country feature toggles for controlled rollouts

API Latency Management
External banking APIs often introduces unacceptable latency in the time-sensitive USSD environment. The team:
Should Implement asynchronous processing for non-critical operations
Create a tiered caching strategy for frequently requested data
Establish circuit breakers to gracefully handle API failures
Optimize database queries for minimal response times

Security in a Constrained Environment
USSD's simplicity presents unique security challenges.

The solution should
Create short-lived JWT tokens for authentication
Encrypted all sensitive data end-to-end
Established strict session expiration policies
Built a fraud detection system monitoring unusual transaction patterns

Real-World Impact
Accessibility: Banking services becomes available to additional customers without smartphones
Scalability: The platform successfully handles more concurrent USSD sessions
User Experience is Paramount Despite technical constraints, focusing on user experience pays dividends. Simple menus, clear instructions, and minimal key presses improves adoption rates.
Caching Transforms Performance: Strategic caching in Redis dodn't just improve performance it fundamentally changes what was possible within USSD's constraints.
Security requires creativity conventional web security approaches needs adaptation for USSD's unique environment, leading to innovative approaches to authentication and encryption.

Conclusion
The USSD banking solution demonstrates that technology constraints need not limit innovation. By embracing modern architecture patterns while respecting the realities of the African telecommunications landscape, Banks should create a system that expands banking access to thousands of customers.
In markets where smartphone and internet penetration continue to grow but remain far from universal, USSD technology bridges a critical gap—bringing essential financial services to everyone with a basic mobile phone. The project stands as a testament to thoughtful design that meets users where they are, rather than where technology trends might suggest they should be.

Managing Payments and Orders in E-commerce: Avoiding Double Debits

Korir Moses — Thu, 13 Mar 2025 05:12:09 +0000

In the fast-paced world of e-commerce, payment processing is a critical component that directly impacts both customer satisfaction and business profitability. One of the most frustrating issues for customers—and potentially costly problems for businesses—is the double debit: when a customer is charged twice for a single purchase. This article explores the causes of double debits in e-commerce systems and presents practical strategies to prevent them.
Understanding the Double Debit Problem
Double debits typically occur due to system design flaws, network issues, or improper handling of payment callbacks. When a customer completes a purchase, multiple events must be synchronized:

The payment gateway must process the transaction
The e-commerce platform must record the order
The inventory must be updated
Confirmation must be sent to the customer

If these processes aren't properly coordinated, issues like double debits can arise, especially when:

The customer clicks the "Pay" button multiple times
Network timeouts occur during payment processing
Payment gateway callbacks are handled incorrectly
Race conditions exist in the order processing workflow

Key Strategies to Prevent Double Debits

Implement Idempotent Operations Idempotency is a property where an operation can be applied multiple times without changing the result beyond the initial application. In payment processing, this means:

Generate a unique idempotency key for each payment attempt
Send this key with each payment request to your payment processor
Configure your system to recognize and reject duplicate payment attempts

// Example of generating an idempotency key
public string GenerateIdempotencyKey(int orderId, int customerId)
{
    return $"{orderId}-{customerId}-{DateTime.UtcNow.Ticks}";
}

Use Transaction IDs Effectively Every transaction should have a unique identifier that follows it throughout the entire payment flow:

Generate the transaction ID at the beginning of the checkout process
Include this ID in all payment gateway communications
Use the ID to track the transaction status in your database
Verify the ID when processing callbacks from payment gateways

Implement Proper Database Design Your database schema should support clean transaction tracking:

Create an Orders table with a clear state machine (e.g., "pending," "processing," "completed")
Establish a separate Payments table that links to orders with a one-to-many relationship
Include transaction status fields that track each step of the payment process
Use database constraints to enforce business rules

Utilize Distributed Locks For high-volume systems, distributed locks can prevent concurrent processing of the same order:

public async Task ProcessOrderPayment(int orderId)
{
    using (var lockResult = await _distributedLock.AcquireLockAsync($"order-payment-{orderId}", TimeSpan.FromMinutes(5)))
    {
        if (lockResult.IsAcquired)
        {
            // Proceed with payment processing
            // Only one instance of this code can run for a specific order
        }
        else
        {
            // Lock not acquired, payment is already being processed
            _logger.LogWarning($"Order {orderId} is already being processed");
        }
    }
}

Implement a Finite State Machine for Orders Design your order processing system as a finite state machine where:

Each order can only be in one state at a time
Transitions between states follow strict rules
Each state transition is atomic and persisted
Payment processing triggers specific state transitions

For example:
Created → PaymentInitiated → PaymentProcessing → PaymentCompleted → Fulfilled_

Design Proper Callback Handling Payment gateways typically send callbacks (webhooks) to notify your system about payment statuses:

Verify the authenticity of each callback
Process callbacks idempotently (handle duplicates gracefully)
Update the order status only if the transition is valid
Implement proper error handling and retry mechanisms

public async Task HandlePaymentCallback(PaymentCallback callback)
{
    // Verify callback signature
    if (!_paymentService.VerifyCallbackSignature(callback))
    {
        _logger.LogWarning("Invalid callback signature received");
        return;
    }

    // Find the order
    var order = await _orderRepository.GetByTransactionIdAsync(callback.TransactionId);
    if (order == null)
    {
        _logger.LogWarning($"Order not found for transaction {callback.TransactionId}");
        return;
    }

    // Check if this callback has already been processed
    if (_callbackRepository.HasBeenProcessed(callback.CallbackId))
    {
        _logger.LogInformation($"Callback {callback.CallbackId} already processed");
        return;
    }

    // Process based on payment status
    switch (callback.Status)
    {
        case "success":
            await _orderService.CompletePaymentAsync(order.Id);
            break;
        case "failed":
            await _orderService.MarkPaymentFailedAsync(order.Id);
            break;
        // Handle other statuses
    }

    // Mark callback as processed
    await _callbackRepository.MarkAsProcessedAsync(callback.CallbackId);
}

Implement Client-Side Protection Prevent multiple submissions from the customer's browser:

Disable the payment button after the first click
Show a "Processing" indicator during payment
Implement clear error messaging if there are issues
Use JavaScript to prevent form resubmission

document.getElementById('paymentForm').addEventListener('submit', function(e) {
    // Disable the submit button
    document.getElementById('submitButton').disabled = true;

    // Show processing indicator
    document.getElementById('processingIndicator').style.display = 'block';

    // Continue with form submission
});

Testing Your Payment System
Regular testing is crucial for maintaining a robust payment system:

Unit Tests: Test individual components of your payment processing system
Integration Tests: Test the interaction between your system and payment gateways
Chaos Testing: Simulate network failures and timeouts to ensure proper recovery
Load Testing: Verify system behavior under high transaction volumes
End-to-End Tests: Simulate complete customer journeys

Conclusion
Preventing double debits in e-commerce requires a combination of careful system design, proper transaction handling, and robust error management. By implementing idempotent operations, effective database design, and proper state management, you can create a payment system that provides a seamless experience for customers while protecting your business from the financial and reputational damage of payment errors.
Remember that payment processing is not just about technical implementation—it's about building trust with your customers. A reliable payment system is a foundation for long-term e-commerce success.

Understanding Switch Statements vs. Switch Expressions in .NET

Korir Moses — Mon, 10 Mar 2025 06:05:07 +0000

Introduction
When writing conditional logic in C#, developers often face choices about the most appropriate control structures to use. Among these options, switch constructs stand out as powerful tools for handling multiple conditions based on a single value. With the evolution of C# and .NET, we now have two distinct approaches: the traditional switch statement and the more modern switch expression introduced in C# 8. This article explores both approaches, clarifying their syntax, benefits, limitations, and ideal use cases to help you make informed decisions in your code.
Switch Statements: The Traditional Approach
Switch statements have been a fundamental part of C# since its inception, providing a clean alternative to lengthy if-else chains when comparing a single value against multiple possibilities:

public static string GetDayType(int day)
{
    switch (day)
    {
        case 1:
        case 7:
            return "Weekend";
        case 2:
        case 3:
        case 4:
        case 5:
        case 6:
            return "Weekday";
        default:
            return "Invalid day";
    }
}

When to use switch statements:

When you need to execute multiple lines of code for each case
When you have complex logic within each case
When you need to use control flow statements like continue or break
When working with side effects (like modifying variables outside the switch)
In scenarios where readability of complex branching logic is important

Potential issues:

Forgetting break statements can cause unexpected "fall-through" behavior where execution continues to the next case
More verbose syntax requires more code
Can be harder to scan and understand at a glance
Prone to errors if proper flow control isn't maintained

Switch Expressions: The Modern Alternative
C# 8 introduced switch expressions as part of the language's movement toward more functional programming paradigms, offering a more concise and expressive syntax:

public static string GetDayTypeExpression(int day) => day switch
{
    1 or 7 => "Weekend",
    >= 2 and <= 6 => "Weekday",
    _ => "Invalid day"
};

When to use switch expressions:

For simple value mappings where each case returns a single result
When using pattern matching features (type patterns, property patterns, etc.)
When you want more readable, compact code
For functional programming approaches where expressions are preferred over statements
When you want compiler enforcement of exhaustiveness (handling all possible cases)

Limitations:

Cannot execute multiple statements per case (single expression only)
Not suitable for complex logic requiring multiple operations
Limited ability to handle side effects
Relatively new feature that may not be familiar to all team members

Tuple Patterns in Switch Expressions
One of the most powerful features of switch expressions is their ability to match on tuples, allowing you to evaluate multiple values simultaneously:

public static string ClassifyPoint(int x, int y) => (x, y) switch
{
    (0, 0) => "Origin",
    (var x1, 0) => $"X-axis at {x1}",
    (0, var y1) => $"Y-axis at {y1}",
    (> 0, > 0) => "First quadrant",
    (< 0, > 0) => "Second quadrant",
    (< 0, < 0) => "Third quadrant",
    (> 0, < 0) => "Fourth quadrant",
    _ => "Error"
};

Tuple patterns allow for extremely concise and readable code when dealing with multiple conditions. You can also use discard patterns (_) for values you don't need:

public static string GetShippingRate(string country, decimal weight) => (country, weight) switch
{
    ("USA", < 1) => "$5.00",
    ("USA", < 5) => "$10.00",
    ("USA", _) => "$15.00",
    ("Canada", < 1) => "$8.00",
    ("Canada", < 5) => "$15.00",
    ("Canada", _) => "$20.00",
    (_, < 1) => "$12.00",
    (_, < 5) => "$25.00",
    _ => "$35.00"
};

Key Differences at a Glance
Switch statements and switch expressions differ in several important ways. While switch statements use more verbose syntax, switch expressions are concise and expression-based. Switch statements can either return a value or not, but switch expressions always return a value. Pattern matching capabilities are limited in switch statements but extensively supported in switch expressions. Switch statements support multiple operations within a case, whereas switch expressions are limited to a single expression per case. Exhaustiveness is not enforced in switch statements, but the compiler checks all cases in switch expressions. Fall-through behavior is possible (and sometimes problematic) in switch statements but not possible in switch expressions. Tuple support is limited in traditional switch statements but excellent in switch expressions. Finally, switch statements have been part of C# since its initial release, while switch expressions were introduced in C# 8 in 2019.
Advanced Pattern Matching with Switch Expressions
One of the most powerful aspects of switch expressions is their enhanced pattern matching capabilities:

public static string DescribeObject(object obj) => obj switch
{
    null => "It's null",
    string s when s.Length == 0 => "Empty string",
    string s => $"String with length {s.Length}",
    int n when n < 0 => "Negative number",
    int n => $"Positive number: {n}",
    Person { Age: > 18 } p => $"Adult named {p.Name}",
    Person p => $"Minor named {p.Name}",
    _ => "Unknown type"
};

This example shows how switch expressions can match on types, properties, and conditions in a highly readable format that would be much more verbose with traditional switch statements.
Performance Considerations
From a performance perspective, both switch statements and expressions generally compile to similar IL code in simple cases. The compiler optimizes switch constructs (both types) into efficient jump tables when possible, particularly for consecutive integer values. For more complex pattern matching scenarios, switch expressions might generate slightly different code, but the performance difference is typically negligible in most applications.
Conclusion
Both switch statements and switch expressions are valuable tools in a C# developer's toolkit, each with their own strengths and appropriate use cases. Switch statements continue to excel in scenarios requiring complex multi-line logic or specific control flow, while switch expressions shine when clarity, conciseness, and functional programming principles are prioritized.
The introduction of switch expressions with tuple support represents a significant advancement in C#'s pattern matching capabilities. This feature allows developers to write more elegant, readable code when evaluating multiple conditions simultaneously, something that would require nested if statements or more complex logic in traditional approaches.
As your codebase evolves, consider gradually adopting switch expressions where they make sense, particularly for pattern matching and tuple-based conditions. By choosing the right construct for each situation, you can write code that is both efficient and expressive, taking full advantage of C#'s rich feature set while maintaining readability and maintainability.

Suitable DB Choice in USSD Application

Korir Moses — Thu, 06 Feb 2025 05:27:47 +0000

USSD (Unstructured Supplementary Service Data) technology, despite its age, continues to be a critical component in modern digital infrastructure, particularly in emerging markets. Its significance extends beyond basic menu-driven applications, serving as a crucial backup system during mobile app downtime and providing essential services to populations with limited internet access. In the banking sector, USSD applications handle millions of daily transactions, making efficient memory management and robust architecture paramount.
Understanding USSD Architecture
Session Management Challenges
USSD sessions present unique challenges compared to traditional web applications. With a strict timeout limit of 180 seconds and limited payload size, every aspect of the application must be optimized for speed and efficiency. The stateless nature of USSD requires sophisticated session management to maintain context across multiple user interactions.
Memory Constraints
USSD gateways impose strict memory limitations per session, typically ranging from 512 bytes to 1KB. This constraint necessitates careful consideration of data structures and serialization formats. Additionally, high concurrency requirements in production environments mean that memory usage must be strictly controlled to prevent resource exhaustion.
Advanced Implementation Strategies
Dynamic Menu System
Rather than traditional hard-coded menus, a dynamic menu system stored in a database offers several advantages:

Real-time menu updates without deployment
A/B testing capabilities for different user segments
Personalized menu options based on user history
Multi-language support through dynamic content loading
Menu versioning and rollback capabilities
Better Localization Based on user Location

State Management Architecture
The implementation utilizes a hybrid approach to state management:

Short-term session data stored in Redis
Long-term user preferences in SQL database
Cached frequently accessed data in distributed cache
Event sourcing for transaction history
Command pattern for action tracking

Performance Optimization Techniques
Several strategies are employed to maintain optimal performance:

Aggressive caching of static menu items
Compression of session data
Batch processing of analytics data
Asynchronous logging and monitoring
Connection pooling for database access

Security Considerations
Data Protection
The application implements multiple security layers:

End-to-end encryption of sensitive data
Secure session management
PIN-based authentication, in which case pin first and pin last
Transaction signing
Ensure no sesinsitive data is logged

Compliance and Auditing
Banking regulations require comprehensive audit trails:

All user actions are logged
Transaction history is immutable
Session data is archived for compliance
Regular security audits are automated

Monitoring and Maintenance
Real-time Monitoring
The system includes comprehensive monitoring:

Session metrics tracking
Performance counters
Error rate monitoring
User journey analytics
Resource utilization alerts

Disaster Recovery
Robust disaster recovery mechanisms include:
We implemented a hybrid system such that incase of a redis issue the app would default to managing user sessions in the main database.
Automatic fail-over
Session state replication
Database mirroring
Regular backups
Recovery point objectives (RPO)

[Code examples follow as in previous version...]
Optimization Techniques
Memory Pooling
The application implements custom memory pooling:

Object pooling for frequent operations
Buffer pooling for network operations
Connection pooling for database access
Thread pooling for concurrent processing

Cache Strategy
Multi-level caching strategy includes:

L1 cache: In-memory application cache
L2 cache: Distributed Redis cache
L3 cache: Database query cache
Cache invalidation patterns
Cache warming strategies

Testing and Quality Assurance
Load Testing
Comprehensive load testing approach:

Simulation of concurrent users
Peak load testing
Stress testing
Endurance testing
Recovery testing

Here are the example code snippets to achieve that
USSD Menu Data Models

    public class UssdMenu
{
    public int Id { get; set; }
    public string Code { get; set; }
    public string Text { get; set; }
    public int? ParentId { get; set; }
    public bool IsEndpoint { get; set; }
    public string ServiceCode { get; set; }
    public virtual UssdMenu Parent { get; set; }
    public virtual ICollection<UssdMenu> Children { get; set; }
}

public class UssdSession
{
    public string SessionId { get; set; }
    public string PhoneNumber { get; set; }
    public string CurrentMenuCode { get; set; }
    public Dictionary<string, string> SessionData { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime LastAccessedAt { get; set; }
}

Redis Session Management

public class RedisSessionManager : ISessionManager
{
    private readonly IConnectionMultiplexer _redis;
    private const int SESSION_TIMEOUT_MINUTES = 5;

    public RedisSessionManager(IConnectionMultiplexer redis)
    {
        _redis = redis;
    }

    public async Task<UssdSession> GetOrCreateSessionAsync(string sessionId, string phoneNumber)
    {
        var db = _redis.GetDatabase();
        var sessionKey = $"ussd:session:{sessionId}";

        var sessionData = await db.StringGetAsync(sessionKey);
        if (!sessionData.HasValue)
        {
            var session = new UssdSession
            {
                SessionId = sessionId,
                PhoneNumber = phoneNumber,
                CurrentMenuCode = "MAIN",
                SessionData = new Dictionary<string, string>(),
                CreatedAt = DateTime.UtcNow,
                LastAccessedAt = DateTime.UtcNow
            };

            await SaveSessionAsync(session);
            return session;
        }

        return JsonSerializer.Deserialize<UssdSession>(sessionData);
    }

    public async Task SaveSessionAsync(UssdSession session)
    {
        var db = _redis.GetDatabase();
        var sessionKey = $"ussd:session:{session.SessionId}";

        session.LastAccessedAt = DateTime.UtcNow;
        var serializedSession = JsonSerializer.Serialize(session);

        await db.StringSetAsync(sessionKey, serializedSession, 
            TimeSpan.FromMinutes(SESSION_TIMEOUT_MINUTES));
    }
}

Conclusion
Building a production-grade USSD application requires careful consideration of memory management, performance optimization, and security. The implementation described here demonstrates how modern architectural patterns and technologies can be applied to create a robust, scalable, and maintainable USSD banking platform. Regular monitoring, testing, and optimization ensure that the system continues to meet the demanding requirements of financial services while providing reliable service to users across all segments of the population.

Building An SAAS in 2025-Week 1

Korir Moses — Tue, 14 Jan 2025 10:02:57 +0000

As Promised that After each week I would document the progress that I have had with the challenges that I have faced. So Lets Dig IN.
Getting Started
Last week, I focused on building the authentication system for my FarmFluent platform. I started by setting up the project structure using Onion Architecture, which helped me organize my code better and maintain a clean separation of concerns. For my database, I chose PostgreSQL.
Initial Setup
I began by initializing the application and implementing MediatR to handle my commands and queries efficiently. This choice made it easier to manage the different authentication flows I needed to build.
Authentication Implementation
My main focus was on creating a multi-role authentication system that would work for all my users. I implemented three distinct roles:

Farmers
Agricultural Experts
System Administrators

One of my key decisions was implementing different authentication requirements for each role. For farmers, I created a simplified authentication system using a four-digit PIN. I made this choice because many of our farmer users have varying levels of digital literacy, I wanted to ensure they could easily access the system without compromising basic security.
For experts and administrators, I implemented more stringent authentication requirements since they have access to sensitive system features and data.
Authentication Features
I successfully implemented several key features:

User signup and login using Microsoft Identity with a custom user model
Role-based authentication with different security levels
Google signup integration for additional login options
JWT implementation for secure token-based authentication

Making Authentication More Accessible
For farmers specifically, I focused on making the authentication process as straightforward as possible. The four-digit PIN system works well for basic access, while still maintaining security through:

Limited login attempts
Account lockout protection
Additional verification for sensitive operations

Database Implementation
I integrated PostgreSQL into my authentication system, which was a practical choice given my existing SQL license couldn't work for this project. This database is handling all user data, authentication records, and session management effectively.
Current State and Next Steps
The authentication system is now functional with:

Complete signup and login flows
Working role-based access control
Google authentication integration
JWT token system implementation

My next steps will focus on:

Adding additional security features
Implementing more robust farmer-focused accessibility options
Expanding the authentication options for experts and administrators
Adding more comprehensive audit logging.

Challenges Faced
One of my main challenges was balancing security with accessibility, especially for farmer users. While a four-digit PIN isn't typically recommended for security reasons, I implemented additional safeguards to protect these accounts while maintaining ease of use.
The integration of multiple authentication methods (local PIN-based, Google OAuth, and standard password-based) required careful planning to ensure all systems worked together seamlessly.
Technical Decisions
Throughout this implementation, I made several key technical choices:

Used Onion Architecture for clean separation of concerns
Implemented MediatR for better command and query handling
Chose PostgreSQL for its robust features and licensing compatibility
Integrated Microsoft Identity for flexible user management
Added Google authentication for additional login options

Looking Forward
While the basic authentication system is now in place, I plan to continue improving it by:

Adding more security features for sensitive operations
Implementing additional accessibility options
Expanding audit logging capabilities
Adding more authentication providers
Work On courses and modules with all their dependent functionalities.

The current implementation provides a solid foundation for these future improvements while meeting our immediate needs for user authentication and access control.
Conclusion
This week's work has resulted in a functional authentication system that serves our diverse user base. While there's still room for improvement, the current implementation successfully balances security requirements with accessibility needs, particularly for our farmer users.

Building An SAAS in 2025

Korir Moses — Sun, 05 Jan 2025 15:24:31 +0000

Happy New Year! One of my resolutions this year is to build a SaaS solution in agriculture and document my journey weekly. My goal is to showcase my skills beyond my day-to-day work while addressing a significant need in this sector.

This idea sprouted from conversations with friends over the holidays about investing in agriculture. Our biggest challenge? None of us are experts in the field. Like many, we’ve heard cautionary tales about "telephone farmers" who face significant losses due to a lack of hands-on expertise. For individuals in tech, the learning curve in unfamiliar fields often involves Googling research papers, watching YouTube videos, or enrolling in courses on platforms like Udemy and Coursera.

Although agricultural courses exist online, they often lack the accessibility and focus needed to make a real impact. In contrast, we’ve seen a rise in educational content on social media about investing in money market funds (MMFs), government bonds, and other low-risk options. While these are great, I believe in the principle of "go big or go home." Agriculture in Africa, with its untapped potential, seems like the perfect opportunity.

Through my research, I noticed that resources for farmers remain disorganized. Most rural farmers rely on WhatsApp and Facebook groups to communicate. However, these platforms often result in cluttered messages and disorganized timelines. My solution? A platform that provides:

Curated Courses: Farmers can enroll in structured lessons.
Organized Communication: A dedicated chat where farmers can ask questions and get expert answers.
Expert Contributions: A space for agricultural experts to share their knowledge through courses.
This week marks the start of building this platform—a farming learning solution. While the features will expand over time, my initial focus is on creating an MVP.

Tech Stack:

Backend: .NET
Frontend: Vue.js
Database: SQL
Stay tuned as I share updates and insights on this exciting journey!