Forem: Akum Blaise Acha

Database Sharding: When to Do It, How to Do It, and When You've Gone Too Far

Akum Blaise Acha — Sun, 05 Apr 2026 10:07:03 +0000

Picture this.

It is 11pm on a Tuesday. You are not on call. You are in bed.
Your phone lights up.

It is your CTO.

"The app is crawling. Users are complaining. The dashboard shows query times above 8 seconds. What is going on?"

You jump on your laptop. You pull up the database metrics. CPU is at 94%. Disk I/O is maxed out. There are 3,000 active connections fighting over the same tables.

You look at the data. Your users table has 180 million rows. Your orders table has 600 million. Every query — no matter how well indexed — is slow because the database is simply carrying too much weight.

You have hit the wall that every growing system eventually hits.

And the word your CTO says next is the one you have been quietly dreading for months:

"I think we need to shard."

This is not a hypothetical. This is a pattern I have seen play out in real teams, real products, real 11pm phone calls. And sharding is the answer — but only if you understand what it actually means, when it actually helps, and where it will quietly make your life harder if you are not careful.

That is what we are covering today.

What Sharding Actually Is

Most engineers have heard the word. Fewer can explain it clearly.
Sharding is the practice of splitting a large database into smaller, independent pieces called shards. Each shard holds a subset of the total data and lives on its own database instance. Together, they hold everything. Individually, each one carries only a fraction of the load.

Think of it like this.

You run a busy post office. Every letter in the country comes through one building. Eventually the building cannot cope — too many letters, too many staff, too many queues. So you split it. Letters A through F go to one building. G through M go to another. N through Z go to a third. Each building now handles a manageable chunk of the total volume.

That is sharding.

The database equivalent is taking your 600 million row orders table and splitting it so that orders for users 1 to 5 million live on shard one, orders for users 5 to 10 million live on shard two, and so on. Each shard is a full, independent database. No shard knows about the others.

The Scenario That Made Sharding Necessary

Let me give you a concrete production scenario to anchor everything that follows.

Imagine you are the lead DevOps engineer at a fintech company. You process payments for businesses across West Africa. You started two years ago with a single PostgreSQL instance on a powerful server — 32 cores, 128GB RAM, fast NVMe storage.

For the first year, it was fine. Queries were fast. The team was happy. You had good indexes, a read replica for reporting, and connection pooling through PgBouncer.

Then growth hit.

Transaction volume tripled in six months. You now have 400 million transaction records. Your payments table is 800GB. Your daily active users crossed 2 million. The read replica helped with reporting but your write load — new transactions, status updates, reconciliation jobs — all still hit the primary.
Here is what you started seeing:

Your P99 query latency went from 40ms to 1.2 seconds. Your autovacuum jobs started falling behind, causing table bloat. Long-running analytical queries locked rows that payment processing needed. Your on-call team was getting paged three nights a week.

You tried everything first. You tuned work_mem. You added partial indexes. You partitioned the payments table by month. You moved analytical workloads to a separate replica. Things improved slightly.

But the write bottleneck remained. One primary database. One write path. No way around it.

That is when sharding became the right conversation to have.

Step One: Choose Your Sharding Key

This is the most important decision in the entire process. Get it wrong and you will rebuild everything six months later.

A sharding key is the field you use to decide which shard a piece of data lives on. In our fintech scenario, the natural candidate is business_id — the ID of the business making payments.
Here is why this works well:

Most queries in a payment system are scoped to a single business. "Show me all transactions for business 1042 this month." That query goes to one shard and one shard only. No cross-shard joins. No scatter-gather across every instance.

Here is what a bad sharding key looks like in the same system:
Sharding by transaction_date. Now a query for a single business's transactions touches every shard because one business has transactions spread across all date ranges. Every read becomes a fan-out across all shards. You have added hardware but made queries slower.

The rule for choosing a sharding key:

Pick the field that appears in the WHERE clause of your most frequent, most critical queries. That field becomes your key.

In most B2B products it is tenant_id or business_id. In consumer products it is often user_id. In time-series systems it is sometimes a combination of entity ID and time bucket.

Step Two: Choose Your Sharding Strategy

Once you have your key, you need to decide how to map a key value to a shard. There are three main approaches:

Range-Based Sharding

You divide the keyspace into ranges. Business IDs 1 to 100,000 go to shard one. 100,001 to 200,000 go to shard two. And so on.

This is simple to understand and easy to implement. But it creates a problem called hotspots. If your newest, most active businesses all have high IDs, shard three is doing all the work while shard one sits quiet. Your load is uneven.

In our fintech scenario, range sharding on business_id would have been a mistake. New business signups were growing fast, which means the highest ID shard would have carried a disproportionate share of new transactions.

Hash-Based Sharding

You run the sharding key through a hash function and use the result to pick a shard. shard = hash(business_id) % number_of_shards.
This distributes data evenly. No hotspots. Every shard gets a roughly equal share.

The tradeoff: range queries become expensive. "Give me all businesses with IDs between 50,000 and 60,000" now potentially touches every shard because hashing destroys the natural ordering of IDs.

For our fintech system, hash-based sharding on business_id was the right call. We query by business ID directly, not by ranges of business IDs. Even distribution mattered more than range query support.

Directory-Based Sharding

You maintain a lookup table — a directory — that maps each key to a shard. Business 1042 is on shard three. Business 8891 is on shard one. The directory decides.

This gives you the most flexibility. You can move a business from one shard to another by updating the directory. You can handle uneven data sizes by putting your largest businesses on dedicated shards.

The cost: the directory itself becomes a critical dependency. If it goes down, nothing can route queries anywhere. You need to cache it aggressively and protect it carefully.

For very large businesses that generate 10x the transaction volume of an average customer, we used a hybrid approach — hash sharding for the majority, with directory overrides that placed our top 20 enterprise clients on dedicated shard instances.

Step Three: Build Your Routing Layer
Once you know your sharding key and strategy, you need something that sits between your application and your databases and routes each query to the right shard.
In our fintech system, we built a lightweight routing service in Python. Every database call went through it. The logic was simple:

`pythondef get_shard(business_id: int, num_shards: int = 8) -> str:
shard_index = hash(business_id) % num_shards
return f"shard_{shard_index}"

def get_db_connection(business_id: int):
shard = get_shard(business_id)
return connection_pool[shard].get_connection()`

The application code stayed clean. Engineers called get_db_connection(business_id) and got back a connection to the right shard. They did not need to know which physical database they were talking to.

For teams using Vitess — which is what YouTube built and later open-sourced — the routing layer is handled for you. Vitess sits in front of your MySQL instances, understands your sharding key, and routes queries transparently. If you are on PostgreSQL, Citus is worth looking at. It turns Postgres into a distributed database with sharding built in.

Step Four: Handle the Hard Problems

This is where most sharding articles stop. This is where the real work begins.

Cross-Shard Queries

Some queries need data from multiple shards. In our system, the finance team needed a report of total transaction volume across all businesses for a given day. That data lives across all eight shards.

We solved this by maintaining a separate reporting database — a denormalized aggregate store — that received summarized data from each shard via a message queue. The finance team queried the aggregate store, not the shards directly. Analytical queries never touched the transactional database.

This is a common pattern: shards handle writes and single-entity reads, a separate store handles cross-shard analytics.

Distributed Transactions

In a single database, a transaction is simple. Either all your changes commit or none of them do.

In a sharded system, a transaction that touches two shards becomes a distributed transaction. This is genuinely hard. Two-phase commit exists but it is slow and fragile. Most teams avoid it.

Our approach: we designed the system so that a single business's data never needed to span shards. A payment is created, updated, and settled on the same shard — the one that belongs to that business. We accepted that cross-business operations would be eventually consistent rather than immediately consistent.

For the cases where we truly needed cross-shard consistency — like a reconciliation job that settled balances — we used an outbox pattern.
Each shard wrote events to an outbox table. A separate worker read those events and applied them downstream. Eventual consistency, but with guaranteed delivery.

Rebalancing

You start with eight shards. Business grows. Eight shards become a bottleneck. You need sixteen.
This is called resharding and it is painful if you have not planned for it.

With hash-based sharding, adding a new shard changes the hash mapping. hash(business_id) % 8 and hash(business_id) % 16 produce different results for the same business. Data that was on shard three might now belong on shard eleven. You have to move it.

We planned for this from day one by using consistent hashing instead of simple modulo hashing. Consistent hashing minimizes how much data moves when you add or remove shards. When we went from eight to twelve shards, only about 25% of data needed to move instead of potentially all of it.

The migration itself ran as a background job — copying data shard by shard, verifying checksums, then flipping the routing config. Zero downtime. But it took three weeks of careful execution.

When Sharding Is the Wrong Answer

Here is the part most engineers skip when they are excited about a new architecture.

Sharding is not always the answer. And reaching for it too early is one of the more expensive mistakes a team can make.

Before you shard, you should have already done all of these:
Proper indexing. A missing index on a 200 million row table can make a query run in 8 seconds that should run in 40 milliseconds. Add the index first.

Connection pooling. PgBouncer or pgpool in front of PostgreSQL handles thousands of application connections without overloading the database.
Read replicas. Move your read traffic — reporting, analytics, search — off the primary. A single primary with two or three replicas handles a surprisingly large amount of load.

Table partitioning. PostgreSQL native partitioning by date or ID range gives the query planner a much smaller surface to scan. This is not sharding — it still runs on one instance — but it solves many of the same query performance problems with a fraction of the complexity.

Vertical scaling. Sometimes the right answer is simply a bigger machine. Moving from 32 cores to 64 cores and from 128GB to 256GB RAM is cheaper and faster than a sharding migration.
Sharding makes sense when:

You have exhausted vertical scaling options

Your write throughput has outgrown what a single primary can handle
Your dataset is so large that even with partitioning, query planning and vacuuming are struggling
You have clear, consistent query patterns that map well to a sharding key

Sharding makes your system harder to operate, harder to query, harder to reason about, and harder to debug. You are trading simplicity for scale. Make sure you actually need the scale before you pay that price.

THE CAREER-READY ENGINEER MOVEMENT BEGINS

Akum Blaise Acha — Sun, 05 Oct 2025 15:57:52 +0000

A few years ago, I met a young developer who had learned Python, JavaScript, AND React.

Yet every time someone asked, “What can you build?” — he froze.
Not because he lacked knowledge.

But because he lacked proof.
That’s when I realized something:

Most developers in Cameroon (and Africa as a whole) don’t have a skills problem — they have a project problem.

They’ve watched tutorials, collected certificates, even finished courses…
But when it's time to show what they’ve actually built, everything disappears into thin air.

Not because they’re lazy — but because nobody ever showed them what real engineering projects look like.

Projects that solve actual African problems.

Not Todo lists.
Not calculator clones.
Not static dashboards with fake data.

I’m talking about:

✅ A system that helps shop owners auto-restock inventory
✅ A Njangi savings tracker
✅ A customer feedback & sentiment tool for SMEs
✅ A delivery ETA estimator for riders navigating Douala traffic

These are the kinds of builds that change how you see yourself.

Not as “someone learning to code,”
but as “an engineer who solves problems.”

I’ve turned that realization into a structured journey.

It’s called The Career-Ready Engineer Challenge — a 90-day framework to help you build 15 real engineering systems, one at a time — with guidance, clarity and accountability.

If this message hit you, then maybe this challenge is yours.

👉 Learn more or join here: https://excelintech.com/b/4rwHN

The One Skill Every Engineer Needs That Isn’t Taught in Bootcamps

Akum Blaise Acha — Sun, 17 Aug 2025 14:33:22 +0000

When I was starting out, I thought being “good” meant writing the cleanest code.

I spent hours perfecting syntax, naming variables, and refactoring functions — convinced that’s what would get me promoted.

Then one day, in a code review, my senior looked at me and said:

“The code looks fine. But walk me through why you did it this way.”

I froze.

I could talk about what I did. But not why. And in that silence, I realized something:
The real skill isn’t just building. It’s explaining your thinking.

Bootcamps Teach Code. Real Life Teaches Communication.

In bootcamps, you ship projects that “work.”
In jobs, you ship projects that must be understood, maintained, and defended.

That’s where communication makes the difference.

Can you explain to a product manager why you chose approach A instead of B?

Can you describe to a teammate how your code flows — without them opening the editor?

Can you justify your design decisions in simple, non-technical language?

If the answer is no, you’ll always feel “junior,” no matter how many languages you know.

The Interview Wake-Up Call

In one DevOps interview, I was asked a simple question:

“Explain how your last CI/CD pipeline worked.”

I thought showing them YAML would be enough. It wasn’t. They wanted me to tell a story.

What problem the pipeline solved

The steps it took

Why I chose that tool

How it reduced errors or saved time

That’s when I understood: the best engineers don’t just build solutions — they translate them into stories everyone else can understand.

Why This Matters

Influence: Senior engineers get promoted because they can explain decisions to stakeholders, not just peers.

Collaboration: Teams move faster when ideas are clear and decisions aren’t hidden in one person’s head.

Trust: Interviewers and managers trust you more when you can break down complex work simply.

How to Build This Skill

You don’t need a communication class. You need practice.

This week, try this:

Take one piece of work you’ve done (a project, script, or pipeline).

Write a short “explainer” for it.

Problem it solved

Tools you used

Why you chose them

One lesson you learned

Share it with a friend, colleague, or even on LinkedIn.

You’ll be shocked how much clearer your own thinking becomes once you write it down.

Final Thoughts

Code gets you hired.
Communication gets you promoted.

Master both — and you stop being “just another developer.”

The #1 Skill That Separates Average Engineers from Top Engineers

Akum Blaise Acha — Sun, 20 Jul 2025 19:57:02 +0000

Most software engineers obsess over tools, languages, and frameworks.

But the ones who grow the fastest?
They master one thing that changes everything:

Thinking in systems.

→ Anyone can write code that works.
→ Top engineers write code that fits.
Fits into the business.
Fits into the architecture.
Fits into the team.

They ask:
• How does this change affect upstream and downstream services?
• How will this scale with more users or data?
• Where can failure occur, and how will we handle it?

It’s no longer about being the "smartest coder".
It’s about being the most strategic.

If you want to move from “good engineer” to “impactful engineer”, stop thinking in features.
Start thinking in systems.

Understanding Two-Factor Authentication: What Every Software Engineer Should Know

Akum Blaise Acha — Sun, 27 Apr 2025 10:48:18 +0000

We've all used 2FA. But as a software engineer, do you know how it works under the hood?

Like we all know, two-factor authentication is a security method that requires two forms of identity before giving someone access to an account.

The first factor is what you know. That’s your password.

The second factor is either what you have or what you are. What you have can be your phone or a security key. What you are can be your fingerprint or your face.

Here’s the flow:

You enter your email or username and password, if the details are correct, the second layer kicks in. That could be an OTP sent to your phone, a code from an authenticator app, or a biometric check.

Once you complete the second step, access is granted. If not, you’re blocked.

As a dev, this is how you can implement 2FA:

Start by storing a shared secret between your app and the user’s authenticator app. You can use libraries.
When the user logs in successfully, generate a time-based one-time password using the shared secret and the current time.
Send a prompt to the user to enter the 2FA code.
Once they enter the code, verify it by comparing it with the one your server generates in real-time using the same secret and time.
If it matches, proceed. If not, reject access.

Avoid using SMS-based 2FA. It’s weak and vulnerable to SIM swap attacks. Go with TOTP or physical keys.

Knowing how 2FA works helps you build more secure products.

And if you're shipping anything that handles sensitive data, you shouldn't treat 2FA like an optional feature.

How I Would Learn Software Engineering If I Had to Start All Over Again in 2025

Akum Blaise Acha — Sun, 27 Apr 2025 09:08:12 +0000

Most people think learning software engineering is all about cramming programming languages and rushing through tutorials.
I used to think the same when I started.

But after several years working professionally, mentoring over 10+ engineers, and publishing 40+ articles on building real tech careers, I see things very differently now.

If I had to start all over again in 2025 — from absolute zero — here’s exactly how I would approach learning software engineering.

And no, it wouldn't begin with "Learn HTML and CSS."

It would begin with something deeper: understanding how everything actually works.

Step 1: Understand How the Internet Works (Before Writing Code)

Before touching any programming language, I would take time to really understand:

What happens when you open a website

How data moves between your browser, servers, and databases

What APIs are, and why they're important

Basics of client-server architecture

Knowing these concepts would give me a mental map to place all the coding skills I’ll eventually learn.

It’s like building a house — you don't start by painting walls. You start by understanding the foundation.

(And honestly, this kind of understanding would have saved me months of confusion early on.)

Step 2: Choose ONE Language and Stick With It

In 2025, it’s very tempting to jump between languages: JavaScript, Python, Rust, Go, PHP, TypeScript...

If I was starting again, I would pick one versatile language (like Python or JavaScript) and stick with it for at least 6–12 months.

Why?
Because mastery beats curiosity at the early stages.

Languages are just tools. The real value is in mastering problem-solving using that tool.

Step 3: Build Real Projects Early (Not Endless Tutorials)

This was a huge mistake I made early on: staying stuck in tutorial loops.

If I started again, I would build my own small projects as early as possible — even if they’re messy.

Simple ideas like:

A to-do list app
A blog API
A simple portfolio website
A weather app using a public API

Every project teaches lessons you can't learn from tutorials: debugging, designing, asking better questions, reading documentation.

Projects build confidence.
Tutorials build dependency.

Step 4: Learn Basic System Design Early

I used to think "system design" was something only senior engineers worried about.
Big mistake.

Even at the beginner level, understanding:

How databases connect to apps
How APIs are structured
How scaling affects apps
How load balancers or caching work ...can help you make smarter choices while coding.

You don’t need to become a system architect overnight.
But you should start seeing your projects like small systems, not isolated pieces of code.

Step 5: Join a Learning Community

Learning software engineering alone is one of the hardest ways to do it.

If I was starting over, I would join a community of learners and engineers immediately.

Not just for help — but for:

Accountability
Motivation when stuck
Exposure to how others think
Opportunities for real-world collaborations

(That’s part of why I created MentorAura — to make this easier for others.)

In tech, community isn’t a "nice to have."
It’s a career accelerator.

Software engineering isn’t about collecting languages.
It’s about solving real-world problems — making something useful, scalable, secure, and reliable.

If you’re just starting out (or even restarting), remember:

Build understanding before building code
Master one thing before chasing everything
Projects over tutorials
Systems over scripts
Community over isolation Every expert you admire today was once a beginner — they just didn't quit.

Stay consistent. Stay curious. Stay building.