v1.2.0: System design and fintech findability pass

The reader-lens audit continues: Sections 24 (System Design with Go)
and 25 (FinTech with Go) got the same findability pass the testing,
security, and core sections received in v1.1.0. Coverage was already
strong; the gaps closed were the topics a practitioner would search
for and not find.

System design (Section 24)

• Rate limiter (24 Section 2): the algorithm family named together for the first time: token bucket (this design's choice), fixed-window counters and their boundary-burst problem, sliding-window logs and their memory cost, sliding-window counters as the approximation, and the production compromise the design actually builds.
• Payment service (24 Section 3): how PSP results arrive is now explicit. Polling was the only ingress; the design now also covers webhook ingress: asynchronous, retried, at-least-once, idempotent by the PSP's event ID, sender verified before parsing, landing in the same outbox-and-ledger path. Polling remains the fallback and the reconciliation backbone.
• Payment service (24 Section 3): the hot-account wrinkle is named in ledger scaling: the house or clearing account serializes postings no matter how you shard; split into sub-accounts and batch.
• Order processing (24 Section 7): "reserve stock" now names the pattern it implements: inventory reservation.

FinTech (Section 25)

• The payment lifecycle (25 Section 1): a new section covers auth, capture, void, refund, chargeback, and dispute as distinct money events: each its own ledger posting with its own idempotency key, with the void-versus-refund distinction and the dispute lifecycle's reliance on the stored audit trail.
• Trial balance (25 Section 2): the account-level statement of the sum-to-zero invariant is named, with why it is the cheapest integrity check you own.
• Chart of accounts (25 Section 2): the fixed catalogue of accounts is named where accounts are introduced, with the audit cost of inventing account names at write time.
• Hot accounts (25 Section 2): the production notes now state the ceiling: one account's throughput is the ledger's; the mitigation is sub-account splitting and batched postings.
• Clearing vs settlement (25 Section 3): reconciliation now states the clock difference: clearing exchanges obligations, settlement moves funds (often T+1), so PSP reports run behind your ledger by design.

Section README tables were updated so every new topic is visible from the section indexes.

Full changelog: v1.1.0...v1.2.0

v1.1.0: Reader-feedback improvements

The first content update since v1.0.0, driven by reader feedback: a
consistency pass over what practitioners would search for and not find.

Content improvements

Security (Section 21)

• Response security headers (CSP, HSTS, nosniff) as one middleware, with the API-only caveat and an OWASP reference (21 Section 4)
• SQL injection named and explained where the defense was previously described only as "parameterized SQL" (21 Section 1)
• CI secret scanning (gitleaks, trufflehog) alongside govulncheck in the supply-chain chapter (21 Section 5)

HTTP (Section 12)

• The response shapes beyond JSON in one place: http.Flusher and server-sent events, gzip compression tradeoffs, ETag conditional requests, and an honest note on when WebSockets outgrow http.Handler (12 Section 3)

Databases (Section 13)

• Bulk writes as a ladder: multi-row INSERT, ON CONFLICT upserts, COPY for large loads, with batch size as a measurement question (13 Section 1)

Testing (Section 10)

• testing/synctest for deterministic time in concurrent tests: virtual clocks, synctest.Wait ordering points, fail-fast on blocked bubbles. Stamped: experimental in Go 1.24, stable in Go 1.25 (10 Section 3)

Concurrency (Section 8)

• sync.OnceFunc and sync.OnceValue documented next to sync.Once, including the no-error-variant caveat (8 Section 4)

FinTech (Section 25)

• ISO 20022 added to the regulatory table with its engineering consequence: message schemas as versioned contracts, translated at the boundary (25 Section 4)

Example correctness

• The memwatch example's owned workers no longer busy-loop: they block on the stop channel and clean up via defer. Same ownership lesson, honest mechanics, and no core burned per worker.

Repository improvements

• Codecov coverage reporting on every CI run (public report linked from the repository)
• pkg.go.dev, stars/forks, last-commit badges and a star-history chart in the README
• awesome-go submission prepared and parked pending the directory's 5-month repository-history requirement

Full changelog: v1.0.0...v1.1.0

v1.0.0: The complete handbook

The first complete release of the Go Handbook for Software Engineers.

What is in it

28 sections, 154 chapters, and 20 tested example packages under one Go module, organized as a ladder from first go build to production distributed systems:

• Foundations: fundamentals, the language, data structures, functions/methods/interfaces
• Core Go: errors, packages and modules, generics, concurrency
• Quality: memory and runtime, testing, tooling
• Backend: HTTP, databases, backend development
• Distributed: microservices, distributed systems, messaging, Kafka with Go
• Production: performance, observability, security, production Go
• Deep Go: internals, system design
• Domain and career: FinTech with Go, interview preparation, open source, projects (ending in the financial transaction platform capstone)

Seven learning paths route through the material for beginners, developers coming from other languages, backend engineers, and engineers targeting distributed systems, FinTech, or interviews.

Quality guarantees

Every claim in this repository is backed by something checkable:

• All 20 example packages compile and pass tests with the race detector and shuffled test order on every commit
• 1,601 internal links verified by a dependency-free link checker on every commit
• gofmt, go vet, and staticcheck clean; weekly govulncheck scheduled
• Version-dependent statements are stamped with the Go version that introduced them, and the most sensitive claims are pinned by compiled examples so they fail CI rather than rot

Using it

Read online starting from the README, or clone and run the examples:

go test ./... -race

Pinning to v1.0.0 gives you a stable reference while the handbook evolves.