[{"data":1,"prerenderedAt":98},["ShallowReactive",2],{"api:\u002Fapi\u002Fconfig:en":3,"api:\u002Fapi\u002Fnotes:en":8,"api:\u002Fapi\u002Fprojects\u002Fraft-kv:en":32},{"email":4,"lang":5,"name":6,"role":7},"hello@ewsirdev.example","en","Ewsirdev","Web developer: websites, landing pages and Go services",[9,16,22,27],{"slug":10,"lang":5,"title":11,"date":12,"summary":13,"project":14,"minutes":15},"double-booking","Double booking: a transaction plus a partial UNIQUE index","2026-10-20","How booking-slots protects against two clients booking the same time at once, and how that protection is tested.","booking-slots",1,{"slug":17,"lang":5,"title":18,"date":12,"summary":19,"project":20,"minutes":21},"lease-and-fencing","Lease and fencing: how a queue neither loses a job nor lets a zombie finish it twice","A worker can crash, stall, or wake up after its job was taken by someone else. How the lease and the lease token in job-queue deal with that on SQLite.","job-queue",2,{"slug":23,"lang":5,"title":24,"date":12,"summary":25,"project":26,"minutes":21},"p95-nearest-rank","p95 in an uptime monitor: the nearest-rank method and what it does not hide","How uptime-monitor computes p50\u002Fp95 latency and uptime, why the nearest-rank method was chosen, and where those numbers can mislead.","uptime-monitor",{"slug":28,"lang":5,"title":29,"date":12,"summary":30,"project":31,"minutes":21},"websocket-from-scratch","WebSocket on the standard library: what really happens under new WebSocket()","Why realtime-rooms has its own RFC 6455 layer, which protocol violations it checks, and why a library is still the better choice for production.","realtime-rooms",{"slug":33,"title":34,"type":35,"stack":36,"description":51,"highlights":52,"run":57,"hue":58,"og":59,"shots":60,"case":68,"case_lang":5,"prev":92,"next":95},"raft-kv","Raft KV: a key-value store on Raft","backend",[37,38,39,40,41,42,43,44,45,46,47,48,49,50],"Go","Raft","Distributed systems","Consensus","stdlib only","HTTP\u002FJSON","SSE","WAL + fsync","Snapshots","Linearizability","Deterministic simulation testing","Vanilla JS","Docker","GitHub Actions","A from-scratch teaching implementation of Raft on the pure stdlib: leader election, log replication, quorum commit, a log and term\u002Fvote on disk with fsync, snapshots with compaction, linearizable reads (read-index) and follower-to-leader redirects. It is tested with a deterministic network and time simulator that checks linearizability; the dashboard can kill the leader and cut the network (demo).",[53,54,55,56],"Raft from scratch on the stdlib, no raft libraries","A deterministic network and time simulator + a linearizability check","Log and term\u002Fvote on disk with fsync, snapshots and compaction","A dashboard to kill the leader and cut the network (demo)","cd raft-kv && set SEED_DEMO=1&& go run .\u002Fcmd\u002Fraft-kv",290,"\u002Fog\u002Fen\u002Fraft-kv.jpg",{"desktop":61,"desktop_sm":62,"mobile":63,"dw":64,"dh":65,"mw":66,"mh":67},"\u002Fshots\u002Fraft-kv-desktop.webp","\u002Fshots\u002Fraft-kv-desktop-sm.webp","\u002Fshots\u002Fraft-kv-mobile.webp",1280,800,390,844,{"about":69,"features":72,"run":82,"notes":87},[70,71],"Raft KV is a cluster of three nodes that agree on the order of writes with the Raft algorithm. The algorithm is written from scratch on the pure Go standard library, with no raft libraries or other dependencies, following the paper by Ongaro and Ousterhout, \"In Search of an Understandable Consensus Algorithm\".","Next to it is a vanilla JS dashboard: node roles, term, commit and the log tail in real time, and in demo mode you can kill the leader or cut the network and watch the cluster elect a new one. This is a teaching implementation: it has not been through Jepsen and is not meant for production.",[73,74,75,76,77,78,79,80,81],"Elections with a random timeout, a vote only for a candidate whose log is not behind; term and votedFor are written to disk before the requests go out","Log replication with a ConflictIndex hint: the leader backs up straight to the start of the conflicting term, not one step at a time","Quorum commit only for entries of the current term (section 5.4.2 of the paper); a new leader appends a no-op right away","Persistence: a WAL with CRC32 and fsync, state.json through a temp file and rename, a torn log tail is truncated on load","Snapshots and compaction by file \"generations\": a crash at any step leaves either the whole old or the whole new state; a lagging follower receives a snapshot","Linearizable reads through read-index with no clocks or leases; a read with ?stale=1 is local and may lag","A raft.Node core with no goroutines or clocks: time arrives through Tick and messages through Step, so the same code runs in the runtime and in the simulator","A deterministic network and time simulator (loss, delay, partitions, crashes) that checks invariants and the linearizability of the history (Wing and Gong)","An SSE dashboard: role, term, commit\u002Fapplied, the log tail; the failure buttons and node stop work only with SEED_DEMO=1",[83,84,85,86],"git clone \u003Crepository on request> raft-kv","cd raft-kv","SEED_DEMO=1 go run .\u002Fcmd\u002Fraft-kv   # dashboard http:\u002F\u002Flocalhost:8098, nodes on 8095-8097","curl -L -X PUT localhost:8096\u002Fkv\u002Fcity -d Berlin   # a follower redirects to the leader",[88,89,90,91],"The cluster is fixed at exactly three nodes, with no dynamic membership or joint consensus. There is no pre-vote or check-quorum: a partitioned follower inflates its term, and a partitioned leader believes it is the leader until it sees a higher term (it does not serve linearizable reads meanwhile).","There are no client sessions or exactly-once. A 504 means \"outcome unknown\": the command may have committed later. Repeating a PUT is safe because it is idempotent.","The verification is home-made, not Jepsen. The simulator has a perfect disk, a snapshot goes out as one message and is held in memory whole, there is no TLS or authentication, and every PUT is a separate fsync.","One hand-made mutation is not caught by the tests: committing entries of earlier terms (figure 8 of the paper) has no dedicated scenario. The -race tests run only in CI (there is no gcc locally), and the Docker image has not been built.",{"slug":93,"title":94},"landing-3d","OKSO T1: 3D landing page",{"slug":96,"title":97},"auth-service","Keyring: an authentication service",1792697892726]