October 2026 Summaries

A Speedscale walkthrough describes using coding-agent skills and Proxymock to create a repeatable local load-test baseline for a Node application before larger holiday checkout rehearsals. It guides users through installing Proxymock in local mode, connecting agent skills, recording traffic from a sample application’s read endpoints, mocking downstream API responses, and replaying the captured traffic with 10 virtual users for 30 seconds. The sample run achieved low recorded latency, 108,072 mock responses, and no mock misses, but its throughput was constrained by the load generator and mock infrastructure rather than the application, so it could not establish app capacity. Users are advised to inspect saved reports, preserve a consistent baseline recording across builds, explicitly document changes to traffic or mock timing, and later expand testing to representative checkout paths, agreed performance targets, dependency failures, duplicate-order safeguards, autoscaling behavior, and separate load-generation infrastructure when needed.

A Kubernetes-based walkthrough shows how Speedscale can record real PostgreSQL traffic from an open-source banking application’s transaction service, including ORM, JDBC driver, connection-pool, and Flyway-generated statements, then replay that traffic directly against a disposable QA database without running the application. After recording nearly 13 minutes of activity containing 3,316 PostgreSQL messages, the captured database traffic was converted into replay tests: a clean-schema regression run matched recorded outcomes 100%, while dropping the transactions table’s description column reduced the match rate to 67.33% and identified the affected Hibernate-generated INSERT and SELECT statements. The same snapshot also supported a one-minute load test with 10 concurrent PostgreSQL sessions, sending 975,946 statements at an average of 16,265 per second with a 7.2 ms p99 latency and matching all recorded outcomes. The walkthrough emphasizes using isolated QA credentials and databases because replays execute real writes, resetting schema and data between comparative load tests, and accounting for recorded session commands such as SET ROLE and SET application_name. It concludes that replaying production-like query traffic can reveal migration regressions and data-growth performance behavior that hand-written API or SQL tests may not capture.

Speedscale replaced a five-year-old scheduled EC2 GitLab CI runner fleet for a 19-project Go monorepo with an ephemeral GitLab Runner deployment on GKE Standard, aiming to eliminate idle compute costs, simplify pipelines, and improve build performance. The former system relied on generated child pipelines, per-job Docker-in-Docker builders, artifact-based caches, repeated tool installation, and a large shared build image, while the new design uses Spot-based job pools that scale to zero, a small on-demand system node for runner availability, and a dedicated persistent BuildKit service with shared layer caching. To address unreliable Spot capacity, the cluster supports several Spot machine families and zones plus a zero-minimum on-demand fallback pool, while admission limits and retry policies reduce excessive pending jobs and manage preemption. The migration also introduced Artifact Registry for Go module proxying and mirrored container base images, GCS-backed remote Go build caching through GOCACHEPROG and gobuildcache, and BuildKit-based CGO cross-compilation using xx, reducing repeated QEMU setup and unnecessary toolchains. The author notes that Cloud NAT egress costs motivated registry mirroring, and describes rebuilding the platform rather than incrementally preserving old assumptions, with AI assistance used to develop the system but production experience driving subsequent corrections.