DPL, 2024 - 2026

Redis Connection Multiplexing

In the Mixx Tanzania app, every Redis call was opening its own connection. At peak that went past the connection limit and caused downtime, so I replaced it with one shared, multiplexed connection.

Company

DPL

Role

Software Engineer, Mixx Tanzania app

Period

2024 - 2026

Region

Tanzania

600k+concurrent sessions without running out of connections

ZeroRedis timeout errors at peak after the change

how it workshow it works

From a connection per request to one shared connection

Pick a step to replay it

The problem

Each request created a new Redis connection. During peak traffic, with 600k+ concurrent sessions, the connection count went past the limit, causing timeouts, runtime errors, and downtime in the Mixx Tanzania app.

What I built

Traced the peak-time timeouts to connection handling: every Redis call opened a new connection instead of reusing one
Replaced it with a single, long-lived multiplexed connection shared across the application, so concurrent commands are pipelined over the same connection
Created that connection once for the application's lifetime instead of per request, so the connection count stays flat however busy it gets
Eliminated the timeout errors during peak traffic and made the platform noticeably more stable

Stack.NET, Redis and Connection multiplexing

Build Once, Promote to Production

DevOpsDPL, 2025 - 2026

Build Once, Promote to Production

Automated CI/CD for the telco agent apps with Docker and Jenkins. The image signed off in UAT on PreProd is the exact image that goes to production, under a new tag, which cut deployment errors by 99%.

99%fewer deployment errors

Built withDocker, Jenkins, CI/CD and .NET

Read case study