I build systems that hold when everything else fails.

Raul Tabares

Senior Software Engineer — distributed systems, event-driven architecture, offline-first design

Demo 1: Offline-First Sync

You're in an operating room. The surgeon is mid-procedure, the circulating nurse is logging every instrument hand-off and milestone on a tablet at the periphery of the sterile field. That tablet is the system of record — it's how the care team coordinates, how the OR schedule stays coherent, how the data that drives efficiency analytics gets born. Everything depends on it keeping up.

Hospital Wi-Fi is not a controlled environment. An OR is full of metal surfaces, active imaging equipment, and anesthesia machines broadcasting across frequencies that politely disagree with 802.11. Dead zones exist right where tablets get held. The network doesn't drop on a schedule — it drops when a C-arm rolls into position, or when the neighboring OR powers up its own gear, or simply because the access point on the other side of a lead-lined wall has been there since 2014. A tablet that stops working when the network drops is not a tablet you can rely on in surgery.

The requirement, then, is non-negotiable: the tablet must keep working regardless of connectivity. That part is tractable — queue the events locally, sync when the connection returns. The hard part starts when you have two tablets in the same room, both capturing workflow state, both going offline at the same time, and both making changes. When they reconnect, you don't have a gap to fill — you have a conflict to resolve. Tablet A recorded that the case moved to "closing" at 14:32. Tablet B, working from a slightly stale local snapshot, recorded the same transition at 14:31 with different attendee data attached. Which one is right? Can they both be partially right? What gets persisted, and what gets surfaced for a human to review?

The demo below simulates exactly this scenario. Two tablets diverge from a shared state, each makes changes in isolation, and then they reconnect. Watch what the sync layer does: how it identifies the conflict, how it applies a resolution strategy, and how it surfaces ambiguity rather than silently discarding data. The system's job is not to pick a winner — it's to give the care team enough information to make the right call without slowing the room down.

The stakes of getting this right extend beyond any single case. Operating room throughput is one of the tightest cost levers in a hospital. Delays compound — a ten-minute overrun in one room cascades into the next case, the next surgeon, the next patient. When the coordination tooling works reliably, that friction disappears. That reliability, at scale across hospital partners, translated into over $219K in quarterly operational savings — not from a feature, but from building a system that doesn't fail when the environment gets difficult.

device a

status: closing

→ status: timeout

→ status: incision

server

status: closing

This demo is best experienced on a desktop browser.

Demo 2: Event Sourcing / Surgical Timeline

Imagine you want to answer a simple question: in a given surgery, when did the first incision happen, how long did closure take, and did the timeout occur before or after the attending left the room? Now imagine needing to answer that question for thousands of surgeries, across dozens of operating rooms, going back two years. If your system stores only the current state of each case — a row in a database that gets updated as the surgery progresses — that information is gone the moment the next update overwrites it. The record says the case is "complete." It does not say what path it took to get there.

This is the fundamental problem with mutable state as a source of truth: updates destroy history. You can add audit columns, bolt on a change-log table, try to reconstruct a timeline from timestamps scattered across a dozen related records. But you'll spend more time reverse-engineering the past from a system that was never designed to remember it than you will actually answering the question. The data model optimized for current state is actively hostile to historical analysis.

The insight behind event sourcing is a shift in what you treat as primary. Instead of storing the current state and trying to derive history from it, you store the history — an append-only log of immutable facts — and derive state from that. The log is the source of truth. "Patient positioned" is an event. "Timeout completed" is an event. "Surgeon scrubbed in" is an event. None of these ever get updated or deleted; they accumulate in the order they occurred. Current state is a projection: you read the log from the beginning and fold each event into your running model. The result is deterministic — given the same event log, you always reconstruct the same timeline, no matter when you run the projection or on what machine.

That determinism is what makes surgical analytics tractable. The CQRS pattern extends the model one step further: the write side and the read side are separated by design. The write model is the event log — every surgical workflow event gets appended there, period. The read model is a separate projection built specifically for the analytics use case: aggregation pipelines that compute case durations, milestone intervals, team benchmarks, and efficiency metrics across the full historical dataset. You can build new read models against the same event log without changing the write side at all. If you need a new analytic — say, time from "wheels in" to first incision, broken down by surgeon — you write a new projection and replay the log. The past becomes queryable in a way it never was before.

The demo below lets you observe this in action. Surgical events get appended to the log in real time as a case progresses. At any point, you can replay the log from the beginning and watch the timeline reconstruct itself, event by event, deterministically. This is not a visualization trick — it is the actual mechanism the system uses to answer "what happened and when." The log is the data. Everything else is derived.

#0INCISION
#1HANDOFF
#2CLOSURE
→
+0ms
+1.2s
+3.4s

This demo is best experienced on a desktop browser.

If you want to talk systems, architecture, or hard problems — find me on LinkedIn.

linkedin.com/in/raultabares