Event Ledger
A lightweight event sourcing framework for understanding how state evolves through time. Built to learn, not to ship.
Documenting the journey of building, exploring, and growing through code. Not a portfolio—rather, a living record of technical evolution.
I believe in learning as a practice, not a destination. Every line of code, every system explored, every problem wrestled with—it's all part of a continuous process of becoming.
This archive documents that process. Not to showcase achievements, but to capture the evolution of understanding. The questions that led to insights. The experiments that failed and taught. The gradual accumulation of knowledge through doing.
Technology, to me, is a medium for thought. Building systems is how I understand complexity. Writing about what I learn is how I make that understanding durable.
Progress measured in understanding, not output. The journey matters more than the destination.
Preferring to understand a few things deeply rather than many things superficially.
Writing to think. Archiving to remember. Sharing to connect.
Understanding how systems communicate through events. Exploring patterns like CQRS, event sourcing, and saga orchestration. Building mental models for distributed state management.
Studying consensus algorithms, distributed transactions, and failure modes. Reading papers on consistency models and building intuition for trade-offs in system design.
Exploring how we interface with complex systems. Interested in cognitive load, interface design patterns, and the psychology of developer tools.
Building personal tools for thought. Experimenting with note-taking systems, knowledge graphs, and workflows that augment cognition rather than just organize tasks.
Experiments, explorations, and things built along the way
A lightweight event sourcing framework for understanding how state evolves through time. Built to learn, not to ship.
A collaborative canvas exploring CRDTs and real-time synchronization. An exercise in understanding conflict-free replicated data types.
Interactive visualization of database query plans. Helped me understand how query engines make decisions about execution.
A growing collection of architectural patterns, trade-off analyses, and design decisions documented while studying large-scale systems.
Visual simulation of the Raft consensus algorithm. Nodes, elections, log replication—made tangible through interaction.
Early exploration into networked thought. A precursor to understanding how ideas connect and evolve over time.
Quick notes, observations, and curiosity-driven explorations
The tension between availability and consistency isn't a bug—it's a fundamental property of distributed systems. Understanding when to embrace eventual consistency versus when to demand strong consistency is a key architectural skill...
read note →Distributed transactions force us to choose between coordination overhead and failure complexity. Sagas offer a different model—compensating actions instead of locks. The trade-off is complexity in the failure path...
read note →Conflict-free replicated data types seem to violate our intuition about distributed state. But they're really just mathematical structures with specific properties— commutativity, associativity, idempotency...
read note →Every abstraction leaks eventually. The question isn't whether to abstract, but when the cost of the abstraction is worth the simplification it provides...
read note →When producers outpace consumers, something has to give. Backpressure is the mechanism by which systems communicate their limits. Understanding flow control is understanding system boundaries...
read note →Documentation isn't just for others—it's for your future self. The act of explaining forces clarity. If you can't explain it simply, you don't understand it well enough yet...
read note →A chronological record of growth and exploration
Deep dive into consensus algorithms, distributed transactions, and the theoretical foundations of reliable systems.
Discovered the power of events as a communication primitive. Built systems that think in terms of state changes rather than commands.
Started studying how large systems are built. Learned that every design is a trade-off, and context determines correctness.
Built and deployed something complete. Learned that shipping is a skill, and production teaches what development cannot.
Started with the basics—HTTP, databases, APIs. Realized that simple concepts combine into complex systems.
Wrote the first line of code. Discovered that programming is thinking made tangible, and was hooked.
"The goal is not to build a portfolio of finished work, but to cultivate a practice of continuous learning. Every project is a question. Every line of code is an exploration. Documentation is how we make the journey visible."
Learning is not linear. It's a spiral—revisiting concepts at deeper levels, connecting ideas across domains, building intuition through practice. The archive captures this spiral, making visible the invisible process of understanding.
Not every experiment succeeds, and that's the point. Failed experiments teach what working code cannot. The value is in the attempt, the hypothesis, the discovery of what doesn't work.
Small, consistent efforts compound. A note here, a project there, a deep dive when curiosity strikes. The archive grows not through grand gestures but through the accumulation of small acts of learning.
Building is thinking. The act of creation forces clarity. When you build, you confront the gap between what you think you know and what you actually understand. That gap is where growth happens.