Seattle • Senior Backend Engineer • Distributed Systems
I’m a Seattle-based senior backend engineer specializing in distributed systems correctness: consensus behavior, coordination boundaries, lease and locking semantics, ordering guarantees, retries, idempotency, fencing, and workflow-state safety under partial failure.
I optimize for correctness boundaries before optimization details. That means making ownership, ordering, retries, idempotency, and failure-handling explicit in the design, so scaling decisions don’t introduce hidden risk later.
In practice, this often means durable command queues, strict workflow state transitions, clear fencing semantics, and observability that makes state and progression understandable during incidents.
I spend most of my systems work around coordination boundaries: who owns work, how ownership changes, and how stale actors are prevented from violating state. That includes lease semantics, fencing tokens, and deterministic progression rules under partial failure.
I favor designs where correctness does not rely on timing luck: explicit authority models, idempotent transitions, and well-defined retry behavior that remains safe during leader change, network partitions, and client retries.
I care about systems that remain understandable under load, partial failure, and evolving requirements. That includes admission control, bounded concurrency, and instrumentation that supports real operational decisions—not only dashboard visibility.
I optimize for predictable behavior during outages and concurrency stress: deterministic retries, idempotent transitions, and state progression rules that remain valid through failover and recovery.
A practical entry point covering the concepts and trade-offs worth studying for senior systems interviews.
Primer • Interviews • Study MapLease correctness, leader time authority, fencing, and failure semantics in distributed systems.
Leases • Raft • CorrectnessPractical overload control patterns for stable distributed systems in production.
Backpressure • Reliability • APIsA practical primer on lock semantics, fencing tokens, and common production pitfalls.
Primer • Distributed Locks • ReliabilityStale-owner protection and monotonic write authorization for correctness-sensitive systems.
Coordination • Correctness • SafetyFailure-path map for crashes, GC pauses, partitions, stale resumes, and degraded quorum conditions.
Reliability • Failure Analysis • CoordinationWhen each consensus family is a good fit and how to choose with operational constraints in mind.
Consensus • Architecture • Trade-offsMost of my distributed-systems writing focuses on correctness under failure: leases, locking, coordination, consensus behavior, and reliability guardrails for production workloads.
If you are entering from interview prep or refresher searches, start with the interview guide and distributed lock primer, then move into the Raft and lease material once you want the deeper correctness argument.
If you’re hiring for distributed systems roles with heavy coordination and correctness requirements, you can review my broader experience on the homepage or connect via contact details.