When working on a product with multiple independent repositories, it is common to have separate repositories for the backend, frontend, mobile application, smart contracts, admin panel, or shared services.

For example:

Product Master Repository
│
├── backend
├── frontend
├── mobile
├── contracts
└── admin

One approach is to combine everything into a monorepo. Another approach is to keep each project as an independent repository and use Git submodules to bring them together under a master repository.

Git submodules are useful when you want to maintain repository independence while still having a single place that represents the complete product.

This article explains how Git submodules work, how to manage branches, how to update repositories, and the commands I use most often.

Every previous post in this series has been quietly leading here. The moment you spread a system across more than one machine — replicas, shards, multiple services — you're doing distributed systems, and distributed systems have their own laws of physics. This final part is about those laws: why the network will betray you, what the CAP theorem really forces you to choose, and how message queues and microservices help you cope.

This wraps up my system design fundamentals series.

The database is where most systems live or die. You can scale stateless app servers all day by adding boxes, but the database holds state, and state is stubborn — it's the part that doesn't parallelize for free. So this post is about the two questions that matter most: which kind of database to pick, and what to do when one machine can't hold your data anymore.

This is part five of my system design fundamentals series.

If I could teach a junior engineer exactly one system design skill, it would be caching. Nothing else gives you as much speed for as little effort — a well-placed cache can turn a database that's melting under load into one that's barely warm. It's also the place people make the most subtle mistakes, because a cache is a second copy of your data, and two copies of anything eventually disagree.

This is part four of my system design fundamentals series. Let's make things fast, then talk about the ways caching quietly bites back.

We keep saying "just add more servers." This post is about the part nobody explains when they say that: how a request actually finds its way to one of those servers, and how the traffic gets spread so no single machine drowns. It's the plumbing of every scalable system, and understanding it removes a lot of hand-waving.

This is part three of my system design fundamentals series, following the posts on scaling and on estimation.

There's a moment in every system design discussion where someone has to answer "okay, but will it actually handle that?" — and the people who freeze are the ones who never learned to estimate. Back-of-the-envelope math has a reputation for being scary, but it's genuinely just multiplication with round numbers. This post covers how I do quick capacity estimates, plus the four-step framework I use to keep a design conversation from turning into a rambling mess.

This is part two of my system design fundamentals series. Part one covered scaling, latency, and availability, which you'll want in your head for the estimation part.

I've been meaning to write down how I actually think about system design for a while. Not the interview-flashcard version, but the mental models I reach for when someone asks "will this hold up when we have a million users?" So I'm turning it into a short series. This first post is about the foundations — scaling, latency, throughput, and availability — because almost every design decision downstream comes back to these four ideas.

If you've ever nodded along to "just add more servers" without being totally sure what that buys you, this one's for you.

Non-Fungible Tokens (NFTs) have revolutionized the way we think about digital ownership and asset representation on the blockchain. In this comprehensive guide, we'll explore what NFTs are, how they work, and dive deep into the ERC-721 standard that made them possible.

What is a NFT?​

A Non-Fungible Token (NFT) is a unique digital token that represents ownership of a specific asset on the blockchain. Unlike cryptocurrencies such as Bitcoin or Ethereum (which are fungible), each NFT is unique and cannot be replaced with something else of equal value.

The only Git guide you need for 95% of your daily development workflow. Save this post or bookmark it — it’s your quick-fix toolkit for everyday Git challenges.

Why This Guide​

Git can feel complicated when you are managing multiple branches, commits, and conflicts. Whether you are a developer, team lead, or project manager, this post walks through real-world Git scenarios and commands that actually work, not just theory.

When people talk about blockchain scalability and speed, you’ll often hear terms like Layer 1 (L1) and Layer 2 (L2). These two layers work together to make blockchain networks more efficient, secure, and ready for mass adoption.

Let’s break it down in simple terms.