Arthur Costaconsumer: you

offset 00 · lag 7

0000key
arthur.costa

Every change, in order.

Arthur Costa

results, as events on their record's partitionconsumer lag 4

0001topic: records
4 partitions
key: domain

The log: ten decisions

Each decision record is an event on a partition keyed by domain, with its outcome on it. Order holds only within a partition, so each has its own cursor and lag. Choose an event to apply its full record to the view below.

How I work: this consumer's guarantees

    Read the whole log as text (10 events)
      0002event AC-002
      replayed

      From batch to change data capture

      Simulation, not production data. Left: a source table whose rows change. Middle: in stream mode every change becomes an event on a log that a consumer applies at once; in batch mode changes wait for the next run. Right: the downstream view; outlined rows are stale.

      reported outcome, AC-002 (not simulated)

      60% → 90%+

      processing success, after moving payment settlement from batch to event streams with change data capture, on Java, Go and Kubernetes.

      0003topic: roles
      retention: forever
      compaction: off

      Roles, a retained topic

      7 role events from the earliest offset, 2017, to the head. Retention is forever and compaction is off: no role is dropped for a newer one. The cursor follows your reading; keys are domains, never employers.

        0004view: stack
        snapshot + fold

        Stack, materialized

        CDC starts from a snapshot, then applies the stream. Left is the snapshot of what I work with. Right is a fold over the ten record events: each technology counts the decisions it appears in. The view is already current; while the consumers read the log above, the tallies of the event being applied light up.

        snapshot · stack

        fold over records · materialized from 10 events

        Technologies by number of decision records that use them
        technologyrecordsids
        00053 more topics

        Other topics

        Three smaller topics, each a short log; the first events of each are shown, the rest open in place.

        0006head of log
        lag 0

        Produce the next event

        The view at the head of the log.
        EOFend of topic

        Why this design

        Concept. “Every change, in order”: I moved payment settlement from batch to event streams with CDC, so the page is a partitioned log and you are its consumer.

        First screen. The pipeline: my results are events on their records' partitions, fanning into the rows of my avatar, the view they build.

        Navigation. Sections are offsets; the bar is your consumer position and lag, with a small view of my face that fills as you read.

        Views from one stream. Records sit on four domain partitions with their own cursors; the stack is a fold over those events; roles are a retained topic.

        Type. Martian Mono is the log (offsets, keys, headings that widen once read); Newsreader is the view, everything you read as prose.

        Colour. Warm white and near-black ink. Ochre, the mid-tone of my skin, has one job: where you are reading now (the current offset in the bar, the reading cursor on the roles track, the face filling in the bar). Simulated consumers, changes and lines are ink and grey.

        Motion and access. Only cursors and applied changes move; the portrait builds once from a faint face and holds; Pause stops everything; reduced motion shows every partition caught up.

        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).