Arthur Costaread 0 of 4 topics

Work leads, own time followsyour copy: 0 of 4 topics applied as you readlongest gap —

Porto, PortugalNine years in production (since 2017)Open to senior backend or platform roles, remote or hybrid

Arthur Costa

Senior backend & platform engineerWhat the follower saw.

Leader: my work, where production writes land first. Follower: my own time, which applies the same concerns later.

I build platforms that hold up in production: moving fleets to the cloud, turning batch into event streams, and, on my own time, execution platforms and safety tooling for coding agents.

Leader · at work writes committed in production

    Follower · own time applies them later

    leader writes · follower applies

    The photo is replicated the same way: writes reach the leader as green outlines and the follower applies them a moment later; then the leader dies, its unreplicated writes are marked with an X and discarded, the follower is promoted, clients retry, and both replicas converge on my face.

    The replication log

    one row per topic · sorted by lag, largest first

    Each row is a write: a concern I first handled at work, in production, and the own-time work where I took the same concern further. Rows are sorted the way a replication dashboard sorts followers, most lag first. The pairing is mine; every fact is from my records.

    Lag is the follower’s first year minus the leader’s first year, from the years on each record. Pairs are made only where both sides have a year; own-time work without one is filed under “Written straight to the follower”.

    Lag and failover, drilled

    two figures from two records

    Two things I have built around, played as small simulations. Each figure has its text equivalent beneath it.

    Batch is lag

    AC-002 · payment settlement, from batch to event-driven

    Text equivalent. Two copies follow the same leader database. The batch copy (the saw-tooth; the shaded area under it is writes not yet replicated) falls further behind all window long and catches up only when the batch runs. The CDC copy (the thin grey line) reads the leader’s change log as it is written, so it is only ever one small step behind, at each change. Moving settlement from the first to the second is what AC-002 did; processing success rose from about 60% to 90%+. The shape is illustrative and has no scale; those two rates are the measured numbers.

    With asynchronous replication, a leader can acknowledge writes that never reach its follower; when it fails, those writes are lost. Clients retry what they cannot confirm, and retries are safe only if each write carries a key the new leader can deduplicate. That is why my course labs reset by key (AC-007), my Firecracker driver is tested against duplicate RPCs (AC-004), and Horus treats a changed worktree as a new job, never a silent retry (AC-003).

    Failover drill: retries by key

    AC-007 idempotent resets by key · AC-004 duplicate RPCs in the failure suite

      Written straight to the follower

      no leader write behind them

      In single-leader replication, followers are read-only. On my own time they are not: these writes started on the follower, one line each, the way a follower’s log reads; the last three went upstream to other projects (↗). None has a year in my records, so none shows a lag and the numbering is not a time order.

        The schema both replicas run

        stack

        Guarantees I keep on either replica

        habits

          Read replicas

          where others read from me

          Send a write

          contact

          Open to senior backend or platform roles, remote or hybrid. Reach me on LinkedIn or GitHub.

          leader · at work
          follower · own time

          In sync: both replicas hold the same state, lag zero. A write sent now lands on the leader first.

          Why this design

          colophon

          Concept. DDIA chapter 5 in a career: work is the leader that takes production writes, my own time is the follower that replays the same concerns later, and the lag between them is measured in years from the records.

          Front page. It is the replication itself: the leader’s committed writes are my results at work, arrows carry them across a lag gutter, and the follower column is my face being applied write by write, with my own-time result on top.

          Information architecture. One replication log, sorted by lag like a replication dashboard: each row pairs a leader write with the follower’s applied version only where both have a year; the earlier roles sit in one outlined leader-only row, and own-time work with no leader write is filed as written straight to the follower.

          Portrait and type. The ribbon portrait is the follower’s state, rows applied top-down as you read; the contact section shows both replicas in sync. Schibsted Grotesk, drawn for a newspaper, sets the headlines and text, because replication is publishing editions of one story; IBM Plex Mono is kept for positions and counters.

          Colour and motion. Newsprint and ink; spruce only for writes in flight and terracotta only for writes lost in failover, always with a word or an X. Writes travel the gutter at a speed set by their lag; every figure is drawn complete at rest and replays from the start when it comes into view.

          Accessibility. The ribbon’s Pause control stops the photo, the rows and both drills; reduced motion shows every end state; figures are hidden from assistive technology and each has its text beside it, and the drill writes its own log.

          Complete profile

          Senior backend & platform engineer · Porto, Portugal

          I build platforms that hold up in production: moving fleets to the cloud, turning batch into event streams, and, on my own time, execution platforms and safety tooling for coding agents.

          Open to senior backend or platform roles, remote or hybrid

          Nine years in production (since 2017)

          Decision records

          2023–2025 · At work · Platform · Delivered

          200+ instances to cloud local zones, with autoscaling

          Compute cost fell by ~70% across 200+ instances.

          ~70% lower compute cost — 200+ instances moved from on-prem and edge sites to cloud local zones, with autoscaling

          200+ instances migrated — with autoscaling, for live sporting-event peaks

          Context and decision

          Context. A real-time platform for live sporting events ran its workloads on on-prem and edge environments.

          Decision. Lead the infrastructure modernization: migrate the workloads to cloud local zones and enable autoscaling, with multi-region load tests before peak events.

          Stack. Cloud local zones · Autoscaling · Go · Python · Locust

          2022–2023 · At work · Payments · Delivered

          Payment settlement, from batch to event-driven

          Processing success rose from 60% to 90%+.

          60% → 90%+ processing success — payment settlement moved from batch to event streams with change data capture

          Context and decision

          Context. A legacy payment and settlement platform ran as batch processing on a monolith.

          Decision. Move the core components to Java and Go, replace batch with streaming and change data capture, containerize on Kubernetes, and centralize logs and dashboards for the SLAs.

          Stack. Java · Go · Streaming · CDC · Kubernetes

          2026 · Own time · Platform · Working system

          Horus: remote execution for builds and agent jobs

          A changed worktree is a new job, never a silent retry; a worktree without a data class never leaves the machine.

          Context and decision

          Context. Builds and coding-agent jobs start on a workstation but need the CPU, isolation and uptime of a remote fleet, without leaking a private worktree or losing work halfway.

          Decision. A local daemon with a socket API and a written durability contract; content-hash sync so a job runs on exactly the bytes submitted; recovery bound to that content; a versioned accounting ledger; gVisor sandboxes on VPS runners behind a data-class gate.

          Stack. Go · Rust · gVisor

          2026 · Own time · Virtualization · Spike

          Firecracker microVMs as a sandbox compute driver

          A failure-injection suite on a KVM host (kill mid-create, simulated reboot, duplicate RPCs, kill points 0–50 ms, a leak counter) and 23 security probes on a 22-item adversarial matrix. An unimplemented check reports SKIP, never PASS. Proposed upstream as OpenShell#4351.

          Context and decision

          Context. Can Firecracker microVMs, with the jailer, back an open-source agent sandbox runtime (OpenShell) through the whole lifecycle, and stay correct when things crash?

          Decision. A compute driver with its own guest kernel, images from a verified catalog, reclamation of the previous run's VMs at start-up, and a guest flush before Stop.

          Stack. Go · Firecracker · KVM

          2026 · Own time · Platform design · Accepted

          Retire my own agent platform; keep the native clients

          Far less to operate; contribution rules now refuse new routers, schedulers and dashboards.

          Context and decision

          Context. My agent-workflow repository had grown a router, a scheduler, a coordinator hierarchy, a provider dispatcher and a dashboard in front of three coding-agent clients.

          Decision. Retire it (19 October 2026). Each client runs natively; the repository keeps shared skills, a small configuration, standalone safety tools and 26 dated decision records.

          Stack. Python · Bash

          2026 · Own time · Platform safety · Accepted

          Safety tools fail closed

          Documented as a tripwire, not a sandbox, so nobody mistakes it for isolation.

          Context and decision

          Context. Coding agents run shell commands in real repositories from three clients with three hook systems; secrets once reached a model through process arguments.

          Decision. One command-safety hook for all three clients; output redaction; long-lived credentials kept out of worker reach; a missing safety dependency refuses instead of being caught and allowed.

          Stack. Python

          2026 · Own time · Distributed systems · Lab

          Course labs on microVMs, behind an mTLS control plane

          A lab's user id stays reserved until its cleanup has succeeded; CA rotation cannot be bypassed by session resumption.

          Context and decision

          Context. A course platform gives every learner a disposable lab machine, created and destroyed constantly by many people at once.

          Decision. A microVM lab runtime with a chaos test that kills VMs mid-session; idempotent resets by key; mutual TLS on a control-plane CA with reload without restart; pinned keyless signing that fails closed.

          Stack. Go · Kotlin · protobuf

          2026 · Own time · Storage & consensus · Study

          A relational database, from storage to Raft

          Built layer by layer as a study; each phase is a commit history.

          Context and decision

          Context. The fastest way to understand a distributed database is to build its layers in order and see where each guarantee comes from.

          Decision. Disk manager, buffer pool, B+ tree, heap file and write-ahead log; SQL parser, planner and Volcano executor; 2PL then MVCC; Raft, Multi-Raft with range sharding, Percolator-style transactions, SSI with hybrid logical clocks, an S3 backend and the PostgreSQL wire protocol.

          Stack. Rust

          2026 · Own time · Sync & security · Working system

          Offline-first sync with signed form-fill

          The extension never fills a form the owner did not approve.

          Context and decision

          Context. A personal job-search tool runs on several desktops plus a browser extension; data must sync without a central source of truth.

          Decision. Tombstones pruned only once every active desktop has applied them; fill tokens signed on the desktop with a P-256 key from the OS keyring; an encrypted vault export; an LLM judge measured against blind readings.

          Stack. Go · Rust

          2025–2026 · Own time · Developer tooling · Shipped v2.1.1

          gitshift: many Git identities, one machine

          Switching on a directory change went from about 3.8 s to about 0.5 s.

          3.8 s → 0.5 s directory switch — gitshift identity switch on directory change, release v2.1.x

          Context and decision

          Context. Several GitHub and GitLab accounts on one machine means juggling keys, identities and signing by hand.

          Decision. One command switches Git author, SSH key, commit signing and the GitHub CLI account, by alias or automatically by directory; releases through GoReleaser and a Homebrew tap.

          Stack. Go · GoReleaser · Homebrew

          Project source

          Experience

          1. Software engineer, core call control

            2025–2026 · Cloud contact-centre platform

            Load tests to inform cost optimization and Kubernetes autoscaling; graceful shutdown and connection draining in a shared Helm chart; CI repaired with quality gates; codebase rules for agentic coding, shared with the team.

          2. Software engineer, platform / backend

            2023–2025 · Real-time platform for live sporting events

            Led the move of on-prem and edge workloads to cloud local zones with autoscaling (AC-001); real-time, event-driven services on serverless and containers; Go and Python automation; Locust multi-region load tests for peak events; CI/CD across GoCD, GitHub Actions, Jenkins, Buildkite, Ansible and Packer; metrics, logs, traces and alerts.

          3. Software engineer, payments / settlement

            2022–2023 · Payment and settlement platform (consulting)

            Led the modernization of a legacy payment and settlement platform to event-driven streaming and CDC (AC-002).

          4. Software engineer, post-purchase

            2021–2022 · E-commerce marketplace, several countries

            Backend services in Go, Java, Node.js and Groovy for post-purchase and payment workflows; faster claim and dispute resolution.

          5. Software engineer

            2019–2021 · Core banking, Brazil

            Monoliths and mainframe-based systems modernized into Java and Spring microservices; migration of microservices to the public cloud under regulatory SLAs.

          6. Associate software engineer, CRM & integrations

            2018–2019 · Fintech CRM

            Real-time CRM features integrated with banking services such as loans, OTP and account management.

          7. Associate software engineer

            2017–2018 · Software house

            CRM and warehouse management systems in PHP and JavaScript.

          How I work

          Also built

          Drover

          Watch and approve agent sessions from any device: a Rust core over UniFFI, pairing scopes bound to the consumed token.

          Rust

          JVM performance labs

          Eleven on-heap versus off-heap lock-free scenarios with JMH, and 13 serialization frameworks behind one endpoint. Numbers not quoted until re-run with raw output.

          Java · JMH

          graphql-federation

          Federation 2 across Java, Go and TypeScript subgraphs, gRPC between services, SLO burn-rate dashboards.

          Java · Go · TypeScript · gRPC

          Ponte

          A management system for tutoring schools: live lessons with recording and consent, TOTP and lockout, a finance ledger ported to Go and checked by replaying a shared corpus.

          TypeScript · Go · PostgreSQL

          deep-engineering-knowledge-base

          An LLM pipeline that writes and checks engineering lessons, with an independent critic that excludes the author.

          Python

          techish-visual

          An engine for animated technical diagrams: a ThorVG WASM renderer and performance budgets in CI.

          TypeScript

          keyframe

          A Linux studio for recording and editing technical videos, with cuts snapped to silence.

          Rust

          java-workflows

          Reusable GitHub Actions for Java teams: a Java 11 to 25 matrix, security scanning and SBOMs.

          GitHub Actions

          Upstream

          OpenShell#4351

          Firecracker compute driver proposal, from AC-004 (open source). · open

          OpenShell#4591

          A gateway reporting "database is locked" under two concurrent clients. · open

          Orca, 10 pull requests

          SSH OAuth forwarding, pairing-offer rotation without restart, security events, isolation from external agent config. · 9 open, 1 closed

          Stack

          Languages
          Go · Java · Python · TypeScript · Node.js · Rust · Kotlin
          Cloud & runtime
          Kubernetes · GKE · GCP · AWS · Helm · Serverless · Firecracker · KVM · gVisor
          Data & messaging
          Kafka · RabbitMQ · Streaming & CDC · PostgreSQL · MongoDB Atlas · Raft · MVCC
          Delivery
          GitHub Actions · GitLab CI · GoCD · Jenkins · Buildkite · Ansible · Packer · Terraform · Locust
          Observability
          OpenTelemetry · Grafana · Loki · Tempo · Mimir · Datadog · Dynatrace · ELK
          Earlier
          Spring · gRPC · Istio · Akka / Pekko · GraalVM · PHP

          Community

          Tech.ish Thoughts, a collaborative tech blog and GitHub organization (actors, JVM serialization and off-heap work, reusable CI, gitshift).

          The Actor Model, at a DevOps community meetup in Porto.

          Mentors Brazilians entering software engineering through an NGO.

          Background

          Associate's degree, Systems Analysis and Development (2016–2018).

          Portuguese (native), English (full professional, C2), Spanish (limited working).