DEV Community: Zeeshan Ali

I Tried to Build a Graph in Rust. Rc and RefCell Were Waiting for Me.

Zeeshan Ali — Tue, 14 Jul 2026 10:59:20 +0000

How Rust’s ownership model pushes you toward index-based graph design

Part of the Data Structures in Rust series.

A dependency manager is a graph. Package A depends on B, B depends on C, and a circular dependency creates a cycle the package manager has to detect and reject. A routing table is also a graph: each location stores connections to neighbouring locations, and finding the shortest path means traversing those connections efficiently. The data structure underlying both is the same, and implementing it in Rust exposes something worth understanding about how ownership shapes design decisions.

Pointer-based linked lists are one of the worst fits for Rust’s ownership model because they require nodes to hold mutable links in both directions. Graphs have the same problem, amplified. A graph node can have any number of edges pointing to any other node, including back to itself. There is no hierarchy, no single direction of ownership, no clean parent-child relationship the compiler can reason about statically. Node A might point to Node B, which points to Node C, which points back to Node A.

Expressing this in Rust forces a choice: reach for Rc> and accept runtime borrow checking, or change the representation entirely and use integer indices into a Vec. The first works for limited cases. The second is how production Rust graph code actually works, and understanding why requires first seeing what goes wrong with the pointer approach.

The Rc> approach and what it costs you

A graph node needs to hold edges to other nodes. Since multiple nodes can share ownership of a single node (A points to B and C also points to B), Box is off the table: it enforces single ownership. Rc solves the sharing problem by keeping a reference count and dropping the allocation when that count reaches zero.

The problem is that graph edges are usually relationships, not ownership relationships. Rc treats every edge as ownership, which is why cycles become memory leaks. After all external references disappear, each node in a cycle still owns the other through its edge list, leaving both reference counts above zero. Neither allocation ever gets cleaned up. Rc is reference counting only, not a cycle-detecting garbage collector.

Rc is also immutable by default. Mutating the value inside an Rc through a shared reference requires RefCell, which moves the borrow check from compile time to runtime and panics if you violate it.

use std::rc::Rc;
use std::cell::RefCell;

type NodeRef = Rc<RefCell<Node>>;
#[derive(Debug)]
struct Node {
    value: i32,
    edges: Vec<NodeRef>,
}
impl Node {
    fn new(value: i32) -> NodeRef {
        Rc::new(RefCell::new(Node {
            value,
            edges: Vec::new(),
        }))
    }
}
struct Graph {
    nodes: Vec<NodeRef>,
}
impl Graph {
    fn new() -> Self {
        Graph { nodes: Vec::new() }
    }
    fn add_node(&mut self, value: i32) -> NodeRef {
        let node = Node::new(value);
        self.nodes.push(Rc::clone(&node));
        node
    }
    fn add_edge(&self, from: &NodeRef, to: &NodeRef) {
        from.borrow_mut().edges.push(Rc::clone(to));
    }
}

The memory leak from a cycle:

Continue reading on Systems Engineering Notes »

I Stopped Reaching for Stack and Queue in Rust. Here Is What I Use Instead

Zeeshan Ali — Mon, 06 Jul 2026 12:47:47 +0000

Part of the Data Structures in Rust series.

After the linked list article, where the borrow checker fought every design decision, and the binary tree article, where ownership turned out to fit the structure naturally, I expected the stack and queue to land somewhere in the middle. They did not. The stack was almost insultingly easy. The queue started easy and then revealed a performance trap that the standard library quietly solves for you.

The real lesson from both data structures is not about ownership or lifetimes. It is about what Rust’s ownership model implicitly encourages through performance characteristics, and why Vec ends up being the right answer for both unless you have a very specific reason to do otherwise.

The stack
A stack is LIFO: last in, first out. Push something on, pop it off, peek at the top without removing it. The whole thing in Rust:

pub struct Stack<T> {
    elements: Vec<T>,
}

impl<T> Stack<T> {
    pub fn new() -> Self {
        Stack { elements: Vec::new() }
    }
    pub fn push(&mut self, item: T) {
        self.elements.push(item);
    }
    pub fn pop(&mut self) -> Option<T> {
        self.elements.pop()
    }
    pub fn peek(&self) -> Option<&T> {
        self.elements.last()
    }
    pub fn is_empty(&self) -> bool {
        self.elements.is_empty()
    }
    pub fn size(&self) -> usize {
        self.elements.len()
    }
}

That is the entire implementation. Push appends to the end of the Vec. Pop removes from the end. Both are O(1) amortised. Peek borrows the last element immutably. There is no interesting ownership story here because Vec already owns its elements, and adding or removing from the end never requires touching anything else in the allocation.

The test suite to verify it behaves correctly:

#[cfg(test)]
mod tests {
    use super::*;


#[test]
    fn push_and_pop() {
        let mut stack = Stack::new();
        stack.push(1);
        stack.push(2);
        stack.push(3);

Continue reading on Systems Engineering Notes »

Every Architectural Decision Is a Bet on Which Failure You Can Live With

Zeeshan Ali — Mon, 29 Jun 2026 12:55:11 +0000

At some point in every technical interview, someone will say “it depends on the trade-offs” and then look at you like they have just said something profound. They have not. Saying “it depends on the trade-offs” without being able to name the specific failure each choice produces is roughly equivalent to a doctor saying “medicine has side effects” and then leaving the room. Technically accurate, completely useless, and slightly insulting to everyone present.

The reason trade-off thinking is hard to teach is that most resources explain it backwards. They start with the options and describe what each one is good at. Kafka is good for high throughput. PostgreSQL is good for strong consistency. MongoDB is good for flexible schemas. This is the comparison table approach, and it produces engineers who can recite characteristics but cannot reason about failure, which is the only thing that actually matters in production.

The correct starting point is not the options. It is the failure modes.

Every architectural decision is really a question about which failure you are willing to accept, under what conditions it will appear, and how badly it will hurt when it does. The choice between two reasonable options is always a choice between two different ways your system can break. The skill is knowing which breakage you can recover from and which one ends your evening.

A framework that actually works under pressure

Before getting into specific decisions, here is the four-question framework that every trade-off analysis in this series will use. It sounds simple because it is. Simple frameworks survive contact with a whiteboard at 10am when you have not slept well.

What are we optimising for? Not in the abstract, but concretely: latency, throughput, consistency, operational simplicity, cost, developer velocity. Pick the thing that actually matters for this system.

What are we sacrificing? The honest answer to what the first question costs you. Every optimisation trades against something else. Name it explicitly or it will name itself later, in production, at an inconvenient hour.

What breaks first? The specific failure mode, the conditions under which it appears, and roughly at what scale or load it becomes a real problem rather than a theoretical one.

How do we recover? The concrete path back to normal. Not “add more servers” but what specifically you add, what the recovery sequence looks like, and whether recovery requires a maintenance window or can happen live.

The rest of this article uses that framework to walk through the tensions that run through almost every architectural decision. The subsequent pieces in this series apply it to specific choices: Kafka versus RabbitMQ, SQL versus NoSQL, the outbox pattern, saga versus 2PC, sharding, caching, event sourcing. Each one structured around failure, not features.

Continue reading on Stackademic »

Kafka vs RabbitMQ: Which Failure Mode Are You Buying?

Zeeshan Ali — Sat, 27 Jun 2026 09:46:27 +0000

Most comparisons between Kafka and RabbitMQ read like a real estate listing. Kafka: high throughput, distributed log, great for streaming. RabbitMQ: flexible routing, low latency, great for task queues. Pick the one that sounds like your problem. The comparison table ends, you make a choice, and six months later you are in an incident call trying to explain to your team why the system is behaving in a way nobody anticipated.

The comparison table approach fails because it describes what each system does well and leaves out what each system does when things go wrong. That is the only part that matters in production. The previous piece in this series introduced a four-question framework for trade-off thinking: what are we optimising for, what are we sacrificing, what breaks first, and how do we recover. This piece applies that framework to Kafka and RabbitMQ specifically, because the failure modes of these two systems are not just different in degree, they are different in kind, and choosing the wrong one means you inherit a class of problems your architecture was not designed to handle.

The thing each system is actually optimising for

Kafka is optimised for retaining events and serving them to multiple independent consumers at high throughput. The core data structure is an append-only log. Producers write to the end of the log. Consumers read from whatever offset they last committed. The log persists based on a retention policy you configure. Nothing gets deleted on consumption. Multiple consumer groups can read the same log independently, each maintaining its own position, completely unaware of each other.

RabbitMQ is optimised for routing work to the right consumer and confirming that the work was done. The core data structure is a queue. Producers publish to an exchange. The exchange applies routing rules and pushes messages to one or more queues. Consumers pull from queues and send acknowledgements. When a consumer acknowledges a message, the broker deletes it. The queue exists to be emptied.

These are not different implementations of the same idea. They are different ideas. Kafka is a log that happens to support consumption. RabbitMQ is a work dispatcher that happens to buffer messages while workers are busy. Conflating them because both involve producers and consumers sending data is roughly like conflating a database with a cache because both store data and respond to queries.

Continue reading on Stackademic »