We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Docs sweep: brand ThrottleKit Lens; new Scaling/Policy Plans/Replay pages; 8-tab Lens + Monitor door - Home/_Sidebar: (TUI) -> (Lens), Policy-Plans compare row, links to the new pages - Monitoring-and-the-Lens: rebrand to ThrottleKit Lens, 5 -> 8 tabs (Cost Room/Replay/Plan), Monitor door section - new pages: Scaling-and-the-Fleet (Tier-1 + Tier-2 + leaseWindowed), Policy-Plans, Replay - Tier-1/Tier-2 cross-links + Monitor door across Polyglot/Operations/Federation/Pillar-4/Unified/Distributed/Performance/Middleware
docs(federation): multi-process regional escrow + regional-only outage mode (0.8.5) Adds the TK-1306 user-facing documentation: Outage failure-mode table: - New row: regional-only outage mode (requires regionalEscrow); engine serves from L2 balance during coord outage; re-probes isHealthy() every coordinatorHealthCheckMs (default 5s); resumes on recovery - New row: multi-process within a region sharing a regionalEscrow; in-flight per-region escrow bounded by perKeyBudget instead of M*batch - New row: regional Redis (L2) outage; engine falls through to direct L3 leasing (matches 0.8.4 behavior); federation bound preserved New "Multi-process regional escrow (0.8.5)" section: - The two scenarios where an L2 helps (tight regional sub-bounds + the regional-only outage mode) - Quick-start code with RedisRegionalEscrow + RedisCoordinator wired together; onCoordinatorOutage: "regional-only" - The RegionalEscrow interface contract (lease/refill/release/isHealthy); TestRegionalEscrow as deterministic in-memory mirror - The regional-only outage mode semantics (clock-driven probe, recovery, bound degradation during outage) - Backward-compat note: federate() without regionalEscrow is exactly 0.8.4 - Pointers to examples/federation-regional-escrow.ts and research/regional-escrow/DESIGN.md Soft-deprecates the prior "regional-only (TK-906+) is opt-in" paragraph above, now that the mode is fully wired. Local-only commit; pushed to origin at the 0.8.5 release tag per the standing wiki workflow.
docs(federation): document PostgresCoordinator (0.8.4) Adds the PostgresCoordinator backend to the Coordinator-backends table (now shipped 0.8.4) and a Quick start subsection demonstrating its use. Notes the latency / throughput / HA trade-offs vs RedisCoordinator; both implement the identical GlobalCoordinator interface so they are drop-in interchangeable. References the design doc at research/postgres-coordinator/DESIGN.md. Per the wiki-coupling rule (PLAN.md S2), this commit accumulates locally on tk-wiki master and is pushed only at the 0.8.4 release tag time (alongside the npm publish).
docs(federation): refresh 0.9.0 → 0.8.3 release references (DR-07) Federation #77 ships as 0.8.3 patch (not 0.9.0 minor) per the new DR-07 in research/bigger-bets/PLAN.md §8. Surface is purely additive so a patch is the right semver signal. Federation.md: - Coordinator backends table: 'Shipped 0.9.0' → 'Shipped 0.8.3' (×2) - PostgresCoordinator: '0.9.x follow-up' → '0.8.x follow-up' - SPOF caveat paragraph: 'For 0.9.0' → 'For 0.8.3' Home.md: - Guides table Federation row: '(0.9.0)' → '(0.8.3)' No content change beyond the version reference.
docs(federation): new Federation page + sidebar/home/Distributed-and-Provable cross-links (TK-911) The federation user-facing wiki page for the 0.9.0 release. Pushes to origin happen at release tag time per the local-accumulate-then-push rule (memory/throttlekit-wiki.md). New page Federation.md covers: - Quick start (federate + RedisCoordinator example) - The contribution narrative vs static partition (eval table at K=3) - All four outage shapes + Δ bound per shape - Coordinator backends matrix (TestCoordinator / RedisCoordinator shipped; PostgresCoordinator / Raft 0.9.x / 1.0.x follow-ups) - SPOF caveat + Sentinel/Cluster/Postgres/Raft mitigation ladder - Pointers to the TLA+ spec, BFS twin, DESIGN.md, RESULTS.md Cross-links added: - Home.md table: new Federation row - _Sidebar.md: new Federation link - Distributed-and-Provable.md: new 'Cross-cluster federation' sub-section that says when to use federate() vs the existing twoTier(leased) windowCoupled (essentially, when processes span multiple regional clusters)