How a Go `scratch` container absorbed 1,000+ probes on Day 1 with $0 infra cost

Σωκράτης — Sun, 11 Oct 2026 18:31:59 +0000

Modern web development has become bloated. A simple web application today often requires hundreds of megabytes of node_modules, complex JavaScript bundlers, heavy virtual DOM abstractions, and cloud infrastructure bills that scale out of control.

To solve this, I designed FGOTHS — an architectural stack and framework engineered from First Principles to deliver 100/100 PageSpeed scores, 0ms Total Blocking Time (TBT), and sub-millisecond backend execution times while running in a minimal footprint.

Here is a deep dive into the technical design decisions, data serialization choices, and database access patterns that make FGOTHS fast, secure, and cost-effective.

The Core Philosophy: First Principles Engineering

The primary goal of FGOTHS is to eliminate runtime overhead by shifting as much work as possible to compile time and leveraging native OS/hardware capabilities.

1. Server-Driven UI: Templ + HTMX

Instead of shipping megabytes of client-side JavaScript that parse JSON and reconstruct DOM trees in the browser, FGOTHS compiles user interfaces directly into Go code.

Templ (Type-Safe HTML in Go)

Compile-Time Safety: Templates are written in .templ files and compiled into strongly-typed Go functions. If a variable or component prop is missing, the build fails at compile time.
Zero Runtime Parsing: Unlike traditional HTML templating engines that parse strings at runtime, Templ components are compiled directly into Go bytes buffers.
Extreme Memory Efficiency: Rendering a component allocates almost zero additional heap memory compared to standard string concatenation.

HTMX (Interactivity Without JS Frameworks)

HTML over the Wire: The client requests small HTML fragments instead of heavy JSON payloads.
Zero Main-Thread Blocking: Because there is no JavaScript hydration or complex reconciliation loop running in the browser, Total Blocking Time (TBT) drops to 0ms.

2. High-Throughput Data Transport: FlatBuffers

For high-performance data serialization, internal messaging, or RPC-like communication between services, FGOTHS uses Google’s FlatBuffers instead of JSON or Protocol Buffers.

Why FlatBuffers over JSON?

Zero-Copy Deserialization: FlatBuffers represents data in a flat binary format. Accessing data fields requires zero parsing and zero memory allocations — the program simply reads values directly from the memory buffer offset.
Forward/Backward Compatibility: Schema evolution is supported seamlessly without breaking existing binary buffers.
Minimal CPU Cycles: Eliminates JSON string parsing CPU overhead, which is often a major bottleneck in high-throughput Go web services.

3. Database Layer: SQLite in WAL Mode

Rather than introducing network latency and cloud infrastructure costs with external database clusters, FGOTHS embraces embedded database performance.

SQLite Configurations for Concurrency

Write-Ahead Logging (WAL): Enabled by default via PRAGMA journal_mode=WAL;. Readers do not block writers, and writers do not block readers.
Synchronous Normal: PRAGMA synchronous=NORMAL; guarantees data integrity while avoiding blocking disk I/O on every write transaction.
Busy Timeout & Connection Pooling: Configured to handle concurrent read/write access smoothly under peak loads.
Zero Network Hop: Queries execute directly in the same process memory space, yielding single-digit microsecond response times.

4. Deployment: Static Binaries in `scratch` Containers

The entire stack compiles down to a single static Go binary:

# Compilation flags for stripping debug information and symbols
CGO_ENABLED=0 go build -ldflags="-s -w" -o app .

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo
COPY app /app
USER 65532:65532
ENTRYPOINT ["/app"]

No Shell / No OS: Without /bin/sh, package managers, or extra binaries, attackers cannot execute shell payloads or perform command injection.
Microscopic Container Size: The entire image consists strictly of the compiled binary and necessary CA certs.
R$ 0,00 ($0.00) Infra Overhead: Runs self-hosted on bare metal or small instances behind a Cloudflare Tunnel with zero open inbound ports.

Production Benchmarks & Telemetry
PageSpeed Score: 100/100 (Mobile & Desktop)
Total Blocking Time (TBT): 0ms
First Contentful Paint (FCP): 0.4s
Memory Footprint: Less than 15MB RSS at idle
Live Audit Telemetry: https://srars.tech/audit
GitHub Repository: https://github.com/WhoseBiasDoYallSeek/fgoths-framework

Architecture Overview

Instead of client-side hydration, heavy SPAs, and bloated container operating systems, FGOTHS shifts computational overhead to compile time and uses a zero-allocation pipeline:

graph TD
    subgraph Client["Edge & Client Layer"]
        A[Browser / Mobile Client] -->|HTML over the wire / HTMX| B[Cloudflare Edge & Tunnel]
    end

    subgraph Host["Secure Host - Container FROM scratch (uid 65532)"]
        B -->|Encrypted Egress / Zero Open Ports| C[Go Static Binary]

        subgraph Core["FGOTHS Core Engine"]
            C --> D[Templ Engine<br/>Type-safe Compiled HTML]
            C --> E[FlatBuffers Codec<br/>Zero-Copy Binary RPC/I-O]
            C --> F[Audit & Telemetry<br/>Immutable Probe Logger]
        end

        subgraph Storage["Embedded High-Throughput DB"]
            C --> G[(SQLite Engine<br/>WAL Mode + Sync NORMAL)]
        end
    end

    D -.->|Zero-Alloc Byte Stream| A
    G -.->|Microsecond In-Memory Reads| C

    classDef edge fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#0f172a;
    classDef host fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    classDef core fill:#1e293b,stroke:#ee5d43,stroke-width:2px,color:#f8fafc;
    classDef storage fill:#1e293b,stroke:#22c55e,stroke-width:2px,color:#f8fafc;

    class A,B edge;
    class C host;
    class D,E,F core;
    class G storage;

Server-Driven UI: Templ + HTMX
Instead of shipping megabytes of client-side JavaScript that parse JSON and reconstruct DOM trees in the browser, FGOTHS compiles user interfaces directly into Go code.
Templ (Type-Safe HTML in Go)
Compile-Time Safety: Templates are written in .templ files and compiled into strongly-typed Go functions. If a variable or component prop is missing, the build fails at compile time.
Zero Runtime Parsing: Unlike traditional HTML templating engines that parse strings at runtime, Templ components are compiled directly into Go byte buffers.
Extreme Memory Efficiency: Rendering a component allocates almost zero additional heap memory compared to standard string concatenation.
HTMX (Interactivity Without JS Frameworks)
HTML over the Wire: The client requests small HTML fragments instead of heavy JSON payloads.
Zero Main-Thread Blocking: Because there is no JavaScript hydration or complex reconciliation loop running in the browser, Total Blocking Time (TBT) drops to 0ms.
High-Throughput Data Transport: FlatBuffers
For high-performance data serialization, internal messaging, or RPC-like communication between services, FGOTHS uses Google’s FlatBuffers instead of JSON or Protocol Buffers.

sequenceDiagram
    autonumber
    participant C as Client
    participant R as Go HTTP Router
    participant F as FlatBuffers
    participant D as SQLite WAL

    C->>R: Binary Stream Request
    R->>F: Direct Pointer Read
    F->>D: Query Execution <10us
    D-->>F: Memory Row Fetch
    F-->>R: Byte Slice Response
    R-->>C: Streamed HTML or Binary

Why FlatBuffers over JSON?
Zero-Copy Deserialization: FlatBuffers represents data in a flat binary format. Accessing data fields requires zero parsing and zero memory allocations — the program simply reads values directly from the memory buffer offset.
Forward/Backward Compatibility: Schema evolution is supported seamlessly without breaking existing binary buffers.
Minimal CPU Cycles: Eliminates JSON string parsing CPU overhead, which is often a major bottleneck in high-throughput Go web services.

Database Layer: SQLite in WAL Mode Rather than introducing network latency and cloud infrastructure costs with external database clusters, FGOTHS embraces embedded database performance. SQLite Configurations for Concurrency Write-Ahead Logging (WAL): Enabled by default via PRAGMA journal_mode=WAL;. Readers do not block writers, and writers do not block readers. Synchronous Normal: PRAGMA synchronous=NORMAL; guarantees data integrity while avoiding blocking disk I/O on every write transaction. Busy Timeout & Connection Pooling: Configured to handle concurrent read/write access smoothly under peak loads. Zero Network Hop: Queries execute directly in the same process memory space, yielding single-digit microsecond response times.

Conclusion & Discussion
Discussion for Gophers & DevOps Engineers
Have you experimented with compile-time HTML tools like Templ in Go?
What are your thoughts on using FlatBuffers over JSON for high-throughput Go services?
Let me know in the comments!

I'm building FGOTHS: A Go + Templ + HTMX project generator with SSE/FlatBuffers and HMR

Σωκράτης — Sun, 27 Sep 2026 23:33:15 +0000

I'm building FGOTHS (For The GOTH Stack) for my own studio because I needed a way to bootstrap production-ready Go webapps with zero cloud overhead, no heavy JS frameworks, and a fast dev loop. It generates single static binaries (<10MB) targeting bare FROM scratch containers while delivering 100k+ req/s.

Key Features

Two Presets: api (Flat JSON API) and webapp (MVC + Templ + HTMX).
True HMR: Uses SSE + FlatBuffers to swap Templ HTML fragments in real-time, keeping form states, focus, and scroll position intact.
Zero CGO & Minimal Footprint: Compiles to a ~8.8MB binary with a low dependency surface area.
Embedded Runtime: Native reverse proxy, circuit breaker, health-checked failover, and deployment policies built right into the binary. The project is released under the Apache 2.0 license. I’d love to get feedback from the community on the architecture, the SSE/FlatBuffers HMR implementation, or the embedded runtime design!

📊 Benchmarks & Technical Metrics

FGOTHS is engineered for sustained high throughput, low tail-end latency, and predictable memory overhead.

Below are the metrics captured from load testing environments:

Metric	Measured Value	Architectural Context
Throughput	100,000+ req/s	Sustained load under concurrency
Tail Latency (p99)	~2.2ms	Low tail latency under saturation
Binary Footprint	~8.8 MB	Zero-CGO fully static binary
Container Footprint	< 10 MB	Bare `FROM scratch` deployment

How FGOTHS compares to traditional web frameworks and monolithic stacks:

Feature / Metric	FGOTHS	Go + Fiber / Gin	Next.js / Node	Laravel / Rails
Architecture	Go + Templ + HTMX	Go + Templates	JS / SSR / React	Monolith (PHP/Ruby)
HMR Mechanism	SSE + FlatBuffers	Air / Basic Reload	Fast Refresh / HMR	Livewire / Inertia
State Preservation	Scroll, Focus & Forms	Full Page Reload	React State	Full / Partial
Binary / App Size	~8.8 MB (Static)	~15-20 MB	~150 MB+ (Node)	~50 MB+ (Runtime)
Container Base	`FROM scratch` (<10MB)	Alpine (~20MB+)	Node Alpine (~200MB+)	PHP/Ruby (~300MB+)
CGO / Dependencies	Zero CGO / Minimal	Varies	Massive `node_modules`	Heavy Extensions
Built-in Governance	Proxy, Breaker & Failover	Manual / External	External (Vercel/Nginx)	External (Nginx/Envoy)
Throughput (req/s)	100k+ req/s	~80k-100k req/s	~10k-20k req/s	~2k-5k req/s
p99 Tail Latency	~2.2ms	~3-5ms	~20-50ms	~50-150ms

Why FGOTHS?

Vs. JS Frameworks (Next.js/SvelteKit): You drop the node_modules bloat, complex build pipelines, and high memory footprint while keeping a modern reactive frontend experience using HTMX and SSE-driven hot reloading.
Vs. Standard Go Frameworks (Gin/Fiber): FGOTHS isn't just a router or micro-framework; it's a project generator and embedded runtime that wires up Templ SSR, state-preserving HMR, and production-grade proxy/governance out of the box.

Reproducibility: Benchmark suites, execution scripts, and load profiles are available in the repository under the /benchmarks directory.

Github repo: https://github.com/WhoseBiasDoYallSeek/fgoths-framework

DEV Community: Σωκράτης