Built for the peak.

Arthur Costa

Results

    The event behind this screen: instances rise from a quiet baseline through a load test to the peak, and the peak is my avatar, which resolves in its own colours once every instance is up. The name widens with the instance count.

    The move AC-001 · 2023–2025 · at work · delivered

    From edge sites to the peak

    The work behind the first two results, in the order I did it. Choose a step, or let it play once.

      ~70% lower compute cost across 200+ instances: the reported result of AC-001.

      The drawing shows the order of the move. Dots stand for the 200+ instances (one each on a wide screen, about four each on a phone); in the zones they take my avatar's colours, and at the peak, with every instance up, they resolve into my face. How many run at each step is drawn, not measured.

      Peak 10 instances · 3 node pools

      The fleet, scheduled

      Records scheduled onto the node pools they ran on, read like a placement listing: each record is an instance, each pool a node group, each mark a placement.

      Decision records as instances, with status, result and the technologies they were placed on, by node pool
      NameStatusResultNode: languagesNode: runtime & dataNode: delivery

      Node pools: my full stack

      Scale-in consolidated

      7 roles, one screen

      After the event the fleet consolidates: the history behind the peak, newest first, by domain, never by employer.

      YearsRoleDomainWhat I did
      Also built, upstream, habits and community

      Also built

        Upstream

          Habits

            Community

              Off-peak capacity available

              Capacity for the next event

              Off-peak, scaled in to a 48 × 48 fleet: fewer instances, still recognisably me.

              Why this design

              Concept. “Built for the peak”: my strongest result came from sizing a fleet to live-event traffic, so the page is a fleet scaling along one load curve.

              Navigation. Scrolling is event time; the strip at the bottom is the curve, the playhead and the section links, with a portrait whose resolution follows the load where you are. On a phone it sits at the top of the page instead, so it never covers what you read; the hero's skyline and the move figure each carry their own Pause, in sync with the strip's, and each section ends with a link back to the sections.

              First screen. A skyline of instances with my face at its peak; the name and the result figures widen with the instance count as the fleet scales out.

              The move. AC-001 drawn in its own order: on-prem and edge sites, cloud local zones, autoscaling, a Locust load test, the live event; the instances are dots that take my avatar's colours in the zones and resolve into my face at the peak, while the fleet is a placement listing in words (instance, status, result, node pools with one mark per placement), so each figure has its own form.

              Density follows load. Sparse at baseline, densest at the peak (ten instances scheduled onto three node pools), consolidated after it.

              Type. One variable family, Roboto Flex, whose width axis is the page's voice: the name and result figures widen with the instance count, headings and reading text widen with each section's load (condensed at baseline, wide at the peak), and instance names are set wide, like a scheduler's listing.

              Colour. One small palette with one meaning per colour (status marks vary by form, not colour: filled done, half working, outline trial), the same in the skyline, the move, the strip and the table: ink is capacity running at the peak (and text); warm grey is capacity that has run; a lighter grey is what has not happened yet; outlines are idle capacity; terracotta, a neighbour of my skin tone, means only now or moving (the playhead, the skyline's front, instances in flight, the current step). My avatar's own colours are me, never recoloured.

              Motion and access. The portrait plays once and holds; the move of AC-001 rests on its finished state, plays once and can be stepped by keyboard; Pause stops everything; reduced motion shows end states.

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