Skip to content
Kennedy Mutisya

Kennedy Mutisya · CTO · Systems Engineer · Software Architect

I don’t just build software.
I engineer systems.

I’m a CTO and software engineer who enjoys difficult engineering problems: systems that need to scale, data that needs to move, workloads that need to become asynchronous, and products that cannot afford to become unreliable as they grow.

Explore my workAbout me
years engineering systems
10+
users on platforms I’ve architected
500K+
CoAmana · Nairobi
CTO
System flownominal

Product flows into the application, then through queues with a cache, into data stores with search, into analytics, and out as a reliable system.

product → reliable system

01What I build

Systems that keep working as they grow.

Technologies are evidence, not the headline. These are the kinds of problems I take on, and the tools that tend to show up when I do.

  • 01

    Distributed Systems

    Systems that continue working as workloads and complexity grow.

    Queues · Workers · Idempotency · Backpressure

  • 02

    Data-Intensive Applications

    Pipelines, analytics systems, data stores and intelligence platforms.

    ClickHouse · MySQL · Elasticsearch · Streaming

  • 03

    Financial Infrastructure

    Payments, wallets, marketplaces, BNPL and transaction systems.

    Ledgers · Idempotent payments · Reconciliation

  • 04

    Multi-Tenant SaaS

    Systems designed around isolation, scalability and operational reliability.

    Tenancy models · Per-tenant throttling · Isolation

  • 05

    Communication Infrastructure

    High-volume email, SMS and notification systems and asynchronous processing.

    Redis queues · Deferred webhooks · Provider failover

  • 06

    Developer Platforms

    Internal tools that make complex systems easier to operate and develop.

    CLIs · Docker Compose · Static analysis · CI

02Selected systems

Systems I’ve built.

Not project cards. Engineering case studies: the problem, the constraints, the architecture, the decisions, the trade-offs, and what the system taught me.

FlagshipCommunication infrastructure

High-Volume Campaign Platform

Laravel · Redis · MySQL · ClickHouse · Elasticsearch · AWS · Docker

Evolving a mature, multi-tenant Laravel campaign platform into an asynchronous, observable sending system engineered for billion-scale workloads, without stopping the product.

The system was already mature. The goal wasn’t to rewrite it. The goal was to isolate bottlenecks, introduce better execution paths, and evolve the architecture without breaking existing functionality.
  1. 01

    Recipients

    Segments resolved per tenant

  2. 02

    Streaming

    Cursor-based, never loaded whole

  3. 03

    Queue orchestration

    Chunk, order, pace

  4. 04

    Redis

    Queues · dedup · throttles · cooldowns

  5. 05

    Batch processing

    Workers pull bounded batches

  6. 06

    Send infrastructure

    Providers, failover, webhooks deferred

  7. 07

    Analytics

    Events, not row updates

  8. 08

    ClickHouse

    Per-campaign send data, columnar

Campaign execution path after the redesign · recipients to analytics · names generalised

Key decisions

Five architectural choices carried the redesign. Three of them are here; the case study explains all of them, what each cost, and what they changed.

Read the case study

  • Decision 01

    Stream recipients instead of loading them

    Memory ceilings were the first wall. Cursor-based streaming made the audience size irrelevant to worker footprint and let batching become a tuning parameter instead of a limit.

  • Decision 02

    Put coordination state in Redis, not MySQL

    Deduplication, throttling and cooldowns are high-frequency, short-lived and latency-sensitive. Redis is the right home for that; a relational table under row locks is not.

  • Decision 03

    Defer webhook processing

    Providers deliver events in bursts that had nothing to do with our capacity. Accept, enqueue, process. The database stopped being hammered by someone else’s traffic pattern.

  1. 02

    Amana Market

    Financial & marketplace infrastructure

    The platform behind CoAmana’s market hubs: member onboarding and KYC, buy-now-pay-later ordering, wallets and payout rails, finance automation and analytics, built as an event-driven Laravel monolith where every money-moving step runs off the request thread.

    Laravel · MySQL · Redis · Horizon

    Case study

  2. 03

    MarketView

    Data & intelligence platform

    A data-intensive intelligence platform that turns fragmented market activity into structured, queryable insight.

    Laravel · MySQL · ClickHouse · Redis

    Case study

  3. 04

    Angalia

    Verification infrastructure

    KYC verification for Kenyan businesses: instant validation of National ID, KRA PIN and vehicle registration, exposed as a service others build onboarding on.

    Laravel · MySQL · Redis · APIs

    Case study
All systems

03Developer tooling

Build the missing abstraction, not the entire ecosystem.

Docker Compose already solved container orchestration. What it did not know was how our application, tenancy model, databases and supporting infrastructure fit together. The dev CLI is that missing layer: one consistent interface over the whole development topology.

The interesting engineering point is not the shell script. It is deciding that the abstraction, and only the abstraction, was worth building.

How the CLI works

dev · zsh

$ ./dev --help

$

04Engineering philosophy

How I think about systems.

Principles I keep returning to. None of them are original. All of them were learned by getting them wrong first.

  1. 01

    Find the bottleneck

    Don't rewrite the system because one component is struggling.

    Most systems are not slow. One path in them is. Measure until the bottleneck has a name, then change that path and leave everything that works alone.

  2. 02

    Make expensive work asynchronous

    Queues are not merely an implementation detail. They are a scalability boundary.

    The moment work crosses a queue it can be batched, throttled, retried, paused and observed independently of the request that asked for it.

  3. 03

    Give data the right home

    MySQL isn't ClickHouse. Redis isn't MySQL. Elasticsearch isn't your source of truth.

    Different workloads deserve different storage models. Transactional records, analytical aggregates, ephemeral coordination state and search indexes have different shapes, and forcing one store to do all four is how mature systems slow down.

  4. 04

    Design for failure

    Providers fail. Workers die. Networks disappear.

    Reliable systems are not the ones where nothing goes wrong. They are the ones designed to recover: idempotent jobs, deferred side effects, dead-letter paths and enough observability to know what happened.

  5. 05

    Evolve instead of rewrite

    The best architecture is often the architecture you can introduce without stopping the business.

    Incremental migration, feature flags and parallel execution paths let a running system become something else while it keeps serving customers.

05Engineering notes

Writing about how systems actually behave.

Queues, workers, data stores, developer platforms and the decisions a CTO has to make with incomplete information.

All notes

06Contact

Building something difficult?

I’m interested in hard engineering problems, ambitious products, and systems that need to work at scale.

Get in touch

kenmsh@gmail.com