mateenbagheri

Iran internet ban: How your life can be dictated by where you are born

Mateen Bagheri — Fri, 23 Jan 2026 09:43:00 +0330

It has been six days since the internet shutdown and ban by the regime in Iran. I will post this whenever the connection becomes stable and available, if it ever does.This article is not a complaint about inconvenience. It is a record of what it feels like to live and work under a system that routinely and continiousely cuts you off from the world and then acts shocked and asks why you are falling behind.

In these times of oppression, I lose my hope for the future more than ever before. It’s not like this is my first rodeo. The regime bans the internet in Iran whenever they get the chance and the slightest reason to do so.

I chose a career that heavily relies on having access to global resources and networks. Back when I started studying computer engineering at my university, I was a naive young man with hopes of a great future ahead. I dreamed of a future where I work hard and get results based off my hard work.

Now years have passed, and I have held up my end of the bargain. I worked hard for the past years and tried to gather as much knowledge as I could, considering my limitations and life situations, of course. Yet the results have been diminishing constantly as time goes on. Our currency loses more of its value on a daily basis. We lose our basic human rights as time goes by, and people who fight for a better future are beaten, imprisoned, or killed in the streets.

Do you know how exhausting and tiring fighting against the geographic location you were born into is? To have to try the next VPN, hoping it will work, just to be able to connect to the globe? Watching the little hope you have for google.com tab to load successfully die? I hope not. Most days I feel hopeless. What can I do at this point? I want to motivate myself every day, yet I feel like a fool when I open a book during these hard times, where grocery prices have quadrupled and people are dying in the streets.

My Brave browser has an in app notification telling me that I am “offline”. No Brave! I am not offline. I am excluded. This “you are offline”, to me, is just another reminded that I am deprived of my basic rights.

Due to personal reasons, I chose to stay in this country when all my friends and colleagues decided to leave and migrate to a better one where they wouldn’t have to worry about their lives. Nowadays, those personal reasons are gone, and I want to try to get away from this place. However, due to the politics our masters have opted for, in most companies Iran’s name on your resume will get you rejected faster than having a criminal record. It is not always about skills. It can also be about percieved risk and fear of all the things that can go wrong when trying to hire an Iranian.

Sometimes I feel like being born here is like being born with a constant COVID, and everyone who is not born here will try to avoid you so they can avoid getting into trouble. Maybe being Iranian is contagious.

If I and most people I know had put all these efforts into most other places in the world, we would at least have a normal life. Having a normal life was what most of us wanted anyways and even if somehow, magically, everything starts getting better from today, I will not get my lost 30-ish years back. Acknowledging that is just realism. It is just plain saddening. I just needed to rant about it in a blog post and leave it for the world to see.

If anyone is reading this and you were born in a country where access, safety, and opportunity are taken for granted, cherish it. Talent is everywhere but opportunity is not.

Hope you are having a good day (or night, based on where you live and when you read this). Thanks for reading.

My experience implementing a Raft consensus algorithm through Hashicorp Raft library

Mateen Bagheri — Wed, 07 Jan 2026 17:43:00 +0330

The past few months have been challenging to say the least. During tough times, I find it hard to pour time into my personal projects. However, I started pushing through last month and decided to go back to working on my personal project, Memorabilia. Although it’s a bare minimum project at the moment, it is living rent-free on my mind.

One of the paths I decided to go for in this project is to support replication in it using Raft. I know there will be a latency tradeoff that I am sacrificing due to this decision, but to me, the project is a playground to learn, so I don’t really mind.

This blog post is a collection of small, interesting things I have encountered in my learning of Raft and adding it to Memorabilia.

This is not a technical deep dive and is not meant to be. What the goal for this blog post is, is to set up a baseline on what Raft is, a comparison between two great and well-received libraries written in Go, and what interfaces one needs to implement in order to get a Raft consensus running in one of the two libraries mentioned.

What is Raft?

Based off of Raft paper:

Raft is a consensus algorithm for managing a replicated log.

What is a consensus algorithm? The great challenge in a distributed environment, where there can be multiple instances of our application created, is to reach an agreement on shared decisions (a.k.a.: consensus). Raft is one of the major algorithms that has taken on how to solve this problem originating back in 2013. Even to this date, we see this algorithm, at least some variants of it, making the headlines in industry.

Consensus and, in overall distributed systems, is not a modern problem by any means. We have papers, a paper issued back in 1978 by Leslie Lamport named Time, Clocks, and the Ordering of Events in a Distributed System talking about how ordering of events should be handled in a distributed system. Even before Raft, there were many algorithms having their own take on how to solve consensus in a distributed environment. The most famous and widely used of which is Paxos. However, Raft has a rather simpler take on this issue compared to Paxos, making it easier to learn/implement.

Why adding Raft as a replication protocol shifts my key-value store away from its intended origin and how

As I stated in the prologue, Raft usage in my personal in-memory data store project is a bold choice. As you have seen until now, Raft solves a harder problem than basic in-memory replication. There are tons of simpler protocols that get the job done. By adding this feature to my project, the project stops being just another Redis-like key-value clone, but a distributed, strongly consistent key-value store. I would even argue that replication is not the intent. Replication is just what happens when logs are repeated in the same order thanks to consensus.

Like we’ve seen so far, Raft tackles a much harder problem than what basic in-memory replication really needs. There are tons of simpler protocols that could get the job done. But by adding this feature, the project stops being just another Redis-like key-value clone. Instead, it becomes something else: a distributed, strongly consistent store. And I’d even argue the point isn’t really about replication at all. Replication is just the side effect—it’s what happens when you force logs to repeat in the same exact order, thanks to consensus. That’s the real heart of it.

I’ll take Redis project as an example and try to explain how fundamentally different a project becomes due to this choice:

Redis primarily uses asynchronous master-replica replication for data synchronization. There is no consensus. A primary replica is responsible for replicating data.

This method creates some cons:

If the primary node goes down, there will be data loss.
There is also no ordering guarantee. The only ordering guarantee you will get is the ordering of the primary node.
It is eventually consistent. Eventually being the key word.

And some major pros that cannot be ignored for some use cases:

In a design like Redis’s replication, replication should never block the primary, which reduces latency.
It is simpler to deploy.
Enables real-time use cases.

There is no good or bad in this comparison between a synchronous and asynchronous approach. Just like everything in our field, there are tradeoffs. There are some projects like TiKV going the consensus route to address different requirements for different projects, and I think that’s what I am willing to go for with Memorabilia.

There is no single interface implementation for Raft

At first, I decided to start small and build a really minimal application that uses Raft as its consensus to do three basic operations on a map: Set, Get, and Delete.

When looking around, I came across many libraries, two of which had my attention, one by etcd and the other by Hashicorp. The first thing I noticed was that they differ vastly in the interface implementation they offer.

Hashicorp offers a way more high-level interface design and lets you focus on designing your state machine. On the other hand, etcd’s implementation is way more low-level and thus, it will be harder to implement. This is just a guess, but I believe the reason for this is due to Raft being a core algorithm in etcd that everything is built around it rather than a tool. I am not suggesting that a project like Vault isn’t massively benefiting from a consensus algorithm, but I believe the implementation is not built around it, and having a fine-grained control over the algorithm, even if it’s a plus, is not a priority.
Hashicorp’s raft implementation comes with a built-in integrated log store named Raft BoltDB. This is while [etcd] has its own custom WAL (which stands for Write Ahead Log). You can read more about it here. Since the log is the main source of truth, their different approach to it is a big deal. Here we see again that Hashicorp decided to opt for simplicity rather than fine-grained control over how things are done.
How networking is managed in etcd’s library is your responsibility. However, in Hashicorp’s implementation, this is abstracted (as I will explain further in the implementation section). You will implement a Transport interface.

I, as someone who had close to no experience with a distributed environment, chose to start with Hashicorp’s library because it was simpler to learn and get my hands on. I could focus on learning the core concepts and worry less about the fine-grained implementations. And that’s what I did. Eventually, I might also try to do an etcd implementation. The minimal pure implementation is more preferred for a custom system like mine.

Implementation

Note that from now onwards, we are only discussing the Hashicorp Raft library. As mentioned before, the implementations and interface design between any two libraries may vary.

I also will not dig too deep into implementation. There are many great implementations that have done this better than me. However, what I struggled while trying to do my implementation was understanding the reasoning behind this interface design and how all of its components contribute to a greater picture.

Here is NewRaft function with its documentation:

// NewRaft is used to construct a new Raft node. It takes a configuration, as well
// as implementations of various interfaces that are required. If we have any
// old state, such as snapshots, logs, peers, etc., all those will be restored
// when creating the Raft node.
func NewRaft(
 conf *Config,
 fsm FSM,
 logs LogStore,
 stable StableStore,
 snaps SnapshotStore,
 trans Transport,
) (*Raft, error)

I know it can feel overwhelming at first. Having to implement 5 interfaces seems daunting. But worry not! Based on your needs, you might not have to implement every single one of the ones mentioned above. For example, as mentioned in the article, you can use raftboltdb instance as LogStore and StableStore; You also could use NewTCPTransport provided by the package, or for config, you might want to opt for raft.DefaultConfig() until you want to tinker around or have specific needs. Regardless, knowing what each of them does won’t hurt. If anything, once you understand what problem each interface is responsible for, the design starts to make sense.

In order to make an instance work, you need to implement 4 main interfaces:

FSM interface

FSM stands for Finite State Machine. I will quote Hashicorp’s article on what this is intended to be:

An FSM is a collection of finite states with transitions between them. As new logs are applied, the FSM is allowed to transition between states. Application of the same sequence of logs must result in the same state, meaning behavior must be deterministic.

This interface is, basically, the heart of your application logic and domain. You find yourself tinkering a lot with this interface’s implementation. Raft does not know or care particularly what your application is doing. It only cares about making sure that each command is ordered, replicated, and committed consistently for every node. Raft ensures that the Apply() is called in the same order on each node.

LogStore interface

Consists of a lot of functions, but eventually, its goal is to dictate how our Raft log is stored. Machine state can be rebuilt from repeating raft logs in order. For most use cases, the raftboltdb provided by Hashicorp will do the job. Unless someone specifically needs a WAL implementation for a specific need, there is no need to implement this interface. Hashicorp itself uses the raftboltdb for its own projects, which shows it is stable and reliable.

StableStore interface

StableStore, unlike LogStore, dictates how Raft’s metadata is going to be stored. This has nothing to do with your application data. Information regarding leader election is included. This data is crucial to the application and its safety in case of unexpected system behaviour is needed. Hashicorp keeps this interface minimal and also provides us with a boltdb backend implementation to use.

Transport interface

How two nodes communicate with each other is dictated by this interface. This is where networking comes into play. I will avoid further diving into this interface since all I want to say is that this article does better.

SnapshotStore interface

This interface does exactly what its name suggests it does. Snapshots, like Finite State Machines, are not terms and concepts reserved for the Raft algorithm. Based on the wiki

In computer systems, a snapshot is the state of a system at a particular point in time.

Why do we need snapshots in this algorithm? Not having a snapshot handling method will work at first, but consider what happens in a long-running application where logs are getting appended rapidly. I myself thought at first that snapshots must be optional. But when you think about it, most modern applications will get hurt by not implementing it in the long term. Snapshotting is a simple way to handle an ever-growing log backlog. I will quote section 7 in the raft paper:

Raft’s log grows during normal operation to incorporate more client requests, but in a practical system, it cannot grow without bound. As the log grows longer, it occupies more space and takes more time to replay. This will eventually cause availability problems without some mechanism to discard obsolete information that has accumulated in the log. Snapshotting is the simplest approach to compaction. In snapshotting, the entire current system state is written to a snapshot on stable storage, then the entire log up to that point is discarded.

The greater picture

When I get back to when I decided to start my small implementation. I remember I saw each of these interfaces as a task to be implemented. However, when I finished my implementation, I noticed how little I knew in the beggining. They are not separate as much as I thought they were; quite the contrary they were all building up and supporting other interfaces to reach the same eventual goal: distributed consensus

LogStore ensures every node sees the same order of commands. FSM applies those commands and moves the system from one state to next. StableStore holds metadata that keeps election safe and recoverable. SnapshotStore keeps the system reliable for longer time by preventing all logs growing forever, and finally, Transport binds two nodes together allowing them to communicate to each other.

At the end of the day, Raft isn’t just an algorithm you add to a project. It’s a mindset. It forces you to think about what consistency really means, how systems fail, and what it takes to keep them running. Even if you are trying to learn something trivial like building a key-value store or a complext service or just trying it out, working with Raft changes how you see distributed systems not as a collection of independent nodes, but as a single whole that survives with being dependant in a ironic way.

Thank you for reading. If you’re curious about the implementation or want to follow along as Memorabilia evolves, you can find the project on my GitHub. Feel free to reach out with questions and corrections or just to have a chat on distributed systems. I am not claiming to be an expert in this topic so I may have a few things missed or misrepresent here. Have a great day [ or night depending on where on this orb you live]!

Why startup and corparate environments are desperate for a mindset shift

Mateen Bagheri — Thu, 21 Aug 2025 00:00:00 +0000

Why am I writing about this on a warm evening on my day off?

As I talk with my friends in the industry about our work, why we are satisfied or why not, there is a common particular pattern I see amongst most colleagues of mine. This started feeling like a pattern when I started noticing that colleagues from the biggest corporates and startups, not on the same level but eventually, have the same concern and that is “at some point we started selling rather than building”. And what do I mean by this? I mean that we are more focused on launching new features in a rapid pace rather than building sustainable code bases, reliable products, and trust with users through security and data safety.

Many of our startups/corporates nowadays earn revenue from technical aspects. They are not selling any particular products rather they are selling technical services. So why is the technical aspect of the project always neglected? In this post, I want to talk about the current situation, how we got here, why this is not sustainable, and finally what should be done, at least in my humble opinion.

How did we get here (And why people from product teams are doing the right thing)

In most organizations, the hierarchy itself is creating this imbalance. At the very top are the shareholders, executives, and CEOs whose primary responsibility is to make money and market relevance. Their focus becomes product teams’ focus. Thus, leading us to where we are.

To be fair, product teams are not wrong in what they do. In fact, they are doing exactly what they are supposed to do: push for growth, increase user numbers and numbers in general, and respond ASAP to the market. In an environment where competition is unbelievable, moving fast with new features often feels like the safest, and sometimes the only, way to survive.

However, as my friends and I tend to say, everything has a price, nothing is free. There is a hidden price for every shortcut taken to release faster. A hidden debt that the team will eventually have to pay back. Every time security, performance, or maintainability is delayed in favor of speed, the long-term health of the product is quietly weakened.

So we need to be on the same page that this is NOT a post about why technical teams are right and product teams are wrong. In fact, this is a post about why we should work together to find a middle ground that satisfies both ends. To put it in terms of car manufacturing (even though I vividly know these brands since I am not a car enthusiast), I am not pitching the idea that we all must be McLarens and Lamborghinis. But I think being a Saipa is not what we should be proud of, nor pushing for either.

Why this is not sustainable

At first we are moving fast, I mean very very fast. However, this illusion of progress is not going to last long. Teams are celabrating fast releases but eventually, system becomes harder and harder to maintain. Bugs become harder to fix and scaling becomes a dream that most probably will never become true. You might say, “Okay Mateen! we get it!! but at at least we have a lot of users and making a ton of money, right?”. Well, yes. We do have a lot of users now but

With great power, comes great responsibility. - Uncle Ben from Spider-Man

Now that we have a lot of users, we have many pairs of eyes looking at checkin out our products on daily basis. For users, this situation of ours, eventually shows itself in form of unreliability: apps that crash, services that slow down under load, data that isn’t handled with the safety it deserves. And in today’s world, trust is the real currency. Losing user trust through instability or insecurity is far more costly than any short-term gain from a new feature.

This is insanely ironic. The same energy that made us to grow faster can end up slowing everything down. Engineering teams burn out fixing issues instead of building new capabilities. Product teams face frustrated users instead of loyal ones. Companies spend more energy patching holes than charting the future.

We cannot build a sustainable ecosystem if technology is something we think about later down on the road.

What should be done?

If we agree that we have this imbalance, we need to rethink our view of technology in the companies. Here are some steps I personally think can be great to start:

Leaderships and board members need to understand that technical health is business health. It is not a “nice to have” but rather a “must have.”
Like most problems in our universe, this can be bettered with communication. Product and tech teams need to work less like two opposing forces and see themselves as part of the flow. Product ensures the company grows, while tech ensures it survives.
Finally, engineers themselves must learn to understand business terms. This is a skill that I myself have recently started working more on thanks to a team lead of mine giving me this feedback. When you put yourself in other colleagues shoes, you will be more understanding. So my fellow engineers, this is not a one-sided road.

At the end of the day, sustainable success comes from building, not just selling. Launching new features might win the moment, but building reliable, trustworthy, and scalable technology wins the future. That’s all I had to say. Hope you have a nice evening.