Computer Systems Engineer and Mathematician. I write Rust and build distributed systems.
I just graduated in computer systems engineering and mathematics, and I'm eager to start working and get my career in tech off the ground.
I like problems where the answer is in the fundamentals: consensus, write-ahead logs, the actual bytes going over the wire. Most of what I build starts with me saying "I don't really understand how this works" and ends as something that runs, with the sharp edges written down. Being a mathematician shows in how I work.
I'd rather find the invariant than add a retry.
A distributed key-value store, on a Raft I wrote from scratch.
Rust · tokio · tonic/gRPC · WAL
Raft from first principles: leader election, log replication, log compaction, snapshot install, and membership changes at runtime. Reads are linearizable through the ReadIndex protocol, writes go to a durable append-only WAL with CRC32 integrity checks, and the whole thing reports Prometheus metrics.
It runs standalone, or it embeds as a library the way rqlite and dqlite do. An app can carry
its own replicated, linearizable state with no external database, and watch it change
through an etcd-style subscribe() API.
The core is a pure state machine: step(Message) -> Ready, no I/O and no async. That's what
lets me test consensus without a network. 28 unit tests cover the state machine and storage,
plus integration tests that kill the leader, partition the cluster and heal it, replay the
WAL, and change membership while it's running.
An r/place style canvas where every web server is a full Raft node. Watch the canvas live
Rust · Axum · WebSockets · Fly.io
There's no database behind it. Every pixel is a key in an embedded raft-kv, so painting one
is a command in the Raft log, and quorum has to commit it before the client gets its 200.
paint a pixel on any node → Raft consensus → applied on every replica → pushed to every browser
Browsers get 6-byte binary deltas over WebSocket, fed by a watch API hanging off the apply loop. Every node delivers the same event sequence, so the fan-out works from any replica. On connect, a client subscribes before it snapshots the board, so no pixel can slip through the gap. Kill the leader while people are painting and the cluster re-elects in under a second, without breaking anyone's canvas.
I built it to prove raft-kv held up under a real workload. It's also what pushed raft-kv from a standalone server into a library.
Two merged fixes in nushell, a shell written in Rust:
| PR | Fix |
|---|---|
| #18773 | save now gives an actionable error when structured data has no serializer for the target format |
| #18480 | math commands propagate errors from table columns instead of silencing them |
Both are error handling bugs in a tool I use every day. One swallowed failures quietly, the other failed with a message that told you nothing. Not glamorous, but they're the kind of thing you only find by reading the source instead of working around the symptom.
| Daily | Rust (tokio, axum, tonic, serde), Python, C |
| Systems | Raft & replication, WAL design, gRPC, WebSockets, Prometheus |
| Ops | Docker, Fly.io, GitHub Actions, nginx |
| Also | Leptos/WASM, Tailwind, graph theory in Python |
- Email: emiliocacho19@gmail.com
- GitHub: you're here
I'm actively looking for my first full-time role in backend or distributed systems, and I'm available now.