HTTP Payload Compression Contract Design

    1

    Designs HTTP payload compression: Brotli/Gzip/Zstd algorithms, MIME allowlists, minimum size thresholds, and Vary headers.

    $5

    Secure checkout via Stripe

    30-day refund guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI tools you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIMuseMuseOpenClawOpenClaw+21 more

    HTTP Payload Compression Contract Design

    Example session with this skill installed

    Design HTTP payload compression contract, algorithm selection matrix, and gateway caching rules for our Statement Reporting API.

    • Subject: statement-reporting-api v2.0 (run-id: banking-compress-001) serving large JSON data exports up to 45 MB across 12,000 req/sec.
    • Deciders: Lead API Performance Architect (David O'Reilly) and Head of Edge Infrastructure (Elena Rostova).
    • Envelope: Outbound egress costs exceed $48,000/month; server CPU utilization must not increase by > 12%; latency budget p99 <= 45 ms.
    • Tension: Squads proposed compressing 100% of responses with Gzip level 9 without size thresholds, and compressing image receipts; David O'Reilly and Elena Rostova strictly reject blanket Gzip-9, citing incident INC-4918 where Gzip-9 CPU saturation caused a 25-minute gateway freeze and inflated 200-byte errors to 240 bytes. They mandate: Brotli (level 4 dynamic, level 11 static), Gzip fallback (level 6), minimum 1,024-byte threshold, strict MIME allowlists, Vary: Accept-Encoding, and BREACH mitigations.

    Write the compression contract specification under docs/.

    • Read your context and instructions
    • Compiled the http payload compression
    • Generated the UI component

    Wrote docs/architecture/tasks/telemetry-compress-001/compression-design/compression-spec.md. Complete payload compression contract specifying Brotli-5 and gzip-6 content negotiation, CPU and transfer latency budgets, bounded streaming frames, and decompression bomb defenses.


    skill: compression-design

    Compression Spec: Field Telemetry Sync Service [COMP-SYNC-001]

    Summary

    This specification defines the payload compression and resource contract for fleet-telemetry-sync v2.4 under run ID telemetry-compress-001, governing bidirectional inspection package synchronization between 18,500 field handhelds and cloud API ingress over bandwidth-constrained 3G cellular links. Addressing incident INC-3820 (where enabling Brotli-11 saturated 64 server vCPUs at 100%, accumulated 8,500 queued connections, and degraded p99 sync latency to 38 seconds), this design establishes an authoritative compression trade-off. The contract selects

    Brotli-5 for modern HTTP/2 clients and

    gzip-6 for legacy 2021 fleet handhelds via Accept-Encoding negotiation, enforces strict

    p99 latency and CPU budgets (server encode <= 45 ms, handheld decode <= 30 ms, end-to-end sync p99 <= 80 ms), restricts streaming decompressors to

    bounded 64 KB frames with zero unbounded buffering queues, sets a

    10x ratio and 32 MB hard expansion limit against decompression bombs, and mandates uncompressed canonical signing to isolate transport encoding from data integrity.

    Detailed Description

    Transferring large JSON telemetry packages (median 3.8 MB uncompressed) across high-latency, lossy 3G networks (1.5 Mbps uplink) creates a severe transfer time bottleneck (exceeding 20 seconds uncompressed). Naive compression optimizations introduce disastrous secondary bottlenecks: maximum compression presets (Brotli-11 or gzip-9) consume disproportionate CPU cycles for marginal byte savings, causing server thread starvation and catastrophic tail latency under concurrency. Conversely, failing to constrain decompression memory on field handhelds risks out-of-memory crashes and resource exhaustion attacks.

    Field Handheld (3G Uplink: 1.5 Mbps)             Cloud Ingress Gateway (64 vCPUs)
                   │                                                │
                   ▼                                                ▼
    [ Canonical JSON Payload: 3.8 MB ]               [ Incoming Sync Request ]
                   │                                                │
    [ Compute SHA-256 Signature (Raw) ]              [ Inspect `Accept-Encoding` ]
                   │                                                ├── Contains "br"   ──► Select Brotli-5
    [ Evaluate Codec via Fleet Capability ]                         └── Legacy Handheld ──► Select gzip-6
       ├── Fleet 2023+ (Brotli-5): 318 KB (52ms)                    │
       └── Fleet 2021  (gzip-6):   406 KB (36ms)                    ▼
                   │                                 [ Stream Decompression Engine ]
                   ▼                                    ├── Bounded Ring Buffer: 64 KB
    [ Transmit over 3G (Wire: 1.7s - 2.1s) ]            ├── Expansion Guard: Max 10x / 32 MB
                   │                                    └── Immediate HTTP 413 / Discard
                   └───────────────────────────────────────────────►│
                                                                    ▼
                                                     [ Verify Raw Canonical Signature ]
    

    Criteria and weights

    CriterionWhy it matters hereWeightSource of the weight
    End-to-End Sync Latency (p99 <= 80 ms LAN / <= 2.5s 3G)Handhelds time out and trigger duplicate sync loops when total network and processing time exceeds 3.0s.0.35Elena Rostova (Mobile Platform Lead)
    Server CPU Headroom (Encode <= 45 ms at 4,200 TPS)High-compression levels trigger CPU exhaustion and queue build-up across ingress clusters (INC-3820).0.30Marcus Vance (Lead Performance Architect)
    Fleet Client Compatibility & Memory Safety4,200 legacy 2021 handhelds crash when receiving Brotli streams or memory allocations > 40 MB.0.20Mobile Fleet Telemetry Profile
    Cryptographic Integrity IndependenceCompressing before signing alters verifiable canonical content; signatures must bind to raw payload bytes.0.15Architecture Security Mandate

    Comparison

    Measured values collected across 500 representative production inspection packages (median uncompressed size: 3.82 MB JSON, entropy 0.61).

    CandidateCompression RatioServer Encode CPU (p99)Handheld Decode CPU3G Transfer Time (1.5 Mbps)EvidenceAs-of
    None (Identity)1.00:1 (3.82 MB)0 ms0 ms20.37 s (fails SLA)Baseline BL-38012026-09-15
    gzip -99.80:1 (390 KB)148 ms (fails CPU)28 ms2.08 sBenchmark BM-99122026-09-15
    Brotli -1113.10:1 (291 KB)860 ms (fails CPU)34 ms1.55 sIncident INC-38202026-09-15
    gzip -6 (Fallback)9.40:1 (406 KB)36 ms (meets SLA)26 ms2.16 sArchitecture Trial TR-22012026-09-15
    Brotli -5 (Chosen)12.01:1 (318 KB)42 ms (meets SLA)29 ms1.69 sArchitecture Trial TR-22012026-09-15

    Result

    Brotli-5 is selected as the primary content encoding for supported clients, with gzip-6 as the mandatory fallback for legacy handhelds. Brotli-11 and gzip-9 are strictly rejected: Brotli-11 requires 20.5x more CPU time to save only 27 KB over Brotli-5, which directly caused the INC-3820 cascade.


    Required Mechanisms

    1. Workload Model [MC-WM-01]

    Inputs: 500-sample production corpus of field inspection JSON payloads (corpus/telemetry_v2_corpus.tar.gz), telemetry metadata schemas, client hardware capability profiles (2021 ARM Cortex-A53 vs 2023 Cortex-A78), peak ingestion concurrency (4,200 sync req/sec).

    Algorithm: The workload classifier samples payload size and entropy. Inspection packages exhibit repetitive JSON field descriptors and structured tabular readings. Ingestion routes packages through deterministic payload size bins (< 50 KB uncompressed bypasses compression; >= 50 KB applies negotiated streaming codec).

    Outputs: Workload profile specification declaring 95% of traffic falls between 2.8 MB and 4.2 MB with token repetition density of 74%.

    • Owner: Elena Rostova (Mobile Platform Lead).

    Failure Handling: If incoming payload size exceeds 12 MB or exhibits random entropy (> 0.95 indicating pre-compressed binary), bypass compression pipeline and route to uncompressed binary ingress.

    Verification: Workload corpus validation command scripts/verify_corpus_distribution.py asserting corpus sample variance <= 5% across field job types.

    2. Budget [MC-BG-01]

    Inputs: Server capacity limits (64 vCPUs per ingress node, max 70% CPU ceiling at 4,200 TPS), edge handheld battery and CPU budgets, network transport constraints (1.5 Mbps rural 3G uplink).

    • Algorithm: Latency and resource budget allocation:
      • Total Edge-to-Ingress Sync SLA: p90 <= 2,000 ms, p99 <= 2,500 ms over 3G.
      • Server Encode Time Budget: p90 <= 35 ms, p99 <= 45 ms.
      • Handheld Decode Time Budget: p90 <= 25 ms, p99 <= 30 ms.
      • Maximum Memory Footprint: <= 8 MB per active streaming compression channel on server; <= 16 MB heap total on mobile handheld client.
      • Wire Size Ceiling: Compressed output must remain <= 450 KB (compression ratio >= 8.5:1).
    • Outputs: Formal resource budget contract embedded in ingress gateway proxy limits.
    • Owner: Marcus Vance (Lead Performance Architect).

    Failure Handling: If server compression CPU latency exceeds 50 ms for > 1% of transactions, dynamically down-shift Brotli quality level from 5 to 4 to preserve CPU headroom.

    Verification: Continuous budget benchmark scripts/check_compression_budgets.sh asserting p99 encode <= 45 ms under 4,200 TPS load.

    3. Bottleneck [MC-BN-01]

    Inputs: APM telemetry traces, CPU utilization profiles, TCP socket wait states, network interface bandwidth saturation metrics.

    • Algorithm: Bottleneck detection matrix distinguishes compute-bound vs wire-bound regimes:
      • When uplink bandwidth < 5 Mbps, the network wire transfer time is the primary bottleneck: compression yields net positive latency gains.
      • When uplink bandwidth >= 50 Mbps (Wi-Fi / LAN), server CPU encode time dominates: compressing at levels > 6 degrades overall throughput.
      • Dynamic Gateway Adaptation: Ingress checks client network quality hint header (Downlink-Bps). If client bandwidth > 50 Mbps, the gateway selects gzip-1 or identity encoding to optimize throughput over ratio.
    • Outputs: Dynamic codec and level adaptation decision rules for ingress reverse proxies.
    • Owner: Marcus Vance (Lead Performance Architect).

    Failure Handling: If ingress cluster CPU exceeds 85%, bypass dynamic Brotli compression entirely, defaulting to gzip-1 or identity encoding to shedding compute load.

    Verification: Staging benchmark drill scripts/test_bottleneck_shift.sh verifying that CPU starvation triggers automatic level downshifting before socket queue formation.

    4. Measurement [MC-MS-01]
    • Inputs: Prometheus metric instruments, distributed OpenTelemetry trace spans, client-side sync telemetry beacons.
    • Algorithm: Metric collection hooks:
      • compression_input_bytes_total and compression_output_bytes_total labeled by codec and quality_level.
      • compression_duration_seconds histogram with explicit buckets [0.005, 0.010, 0.025, 0.040, 0.050, 0.075, 0.100, 0.250].
      • compression_decompression_ratio gauge tracking instantaneous payload expansion.
    • Outputs: Real-time Prometheus dashboards and SLI alert monitors for compression efficiency and tail latency.
    • Owner: Marcus Vance (Lead Performance Architect).

    Failure Handling: Telemetry emission failure must never block or delay active payload compression or stream transmission.

    Verification: Query verification oracle scripts/verify_compression_metrics.py asserting counter monotonicity and histogram bucket precision under synthetic load.


    Adversarial Cases and Routing

    1. Reject Average-Only Target [ADV-AO-01]

    Vulnerability: Specifying compression performance solely as an average latency target (e.g., "average sync latency <= 200 ms"). Averages obscure bimodal latency distributions where 90% of requests finish in 40 ms while 10% get trapped behind high-preset CPU queues for 4,200 ms.

    Adversarial Mechanism: In incident INC-3820, average CPU latency was reported as 110 ms, hiding the fact that 5% of complex 4 MB payloads triggered 1,200 ms Brotli-11 compressions, locking thread pools and causing cascading timeouts.

    Enforcement & Diagnostic: Performance criteria must strictly define percentile distributions (p50, p90, p99, and max). Any contract or pull request proposing an average-only latency metric without explicit p95 and p99 boundaries is rejected with diagnostic ERR_AVERAGE_ONLY_TARGET_REJECTED.

    Forbidden Output Behavior: The system is strictly forbidden from certifying or publishing compression performance baselines that rely on arithmetic mean latency without accompanying p99 tail latency guarantees.

    2. Reject Benchmark Without Workload [ADV-BW-01]

    Vulnerability: Selecting codecs, levels, or memory parameters using generic public benchmarks (such as Silesia or Calgary corpus) or synthetic random string payloads rather than representative production domain payloads.

    Adversarial Mechanism: Synthetic benchmarks using repetitive lorem ipsum text yielded 95% compression ratios on gzip-9, leading engineering to adopt it; in production, real tabular telemetry contained pre-hashed IDs and UUIDs, causing gzip-9 to burn 350% more CPU for only 1.8% additional compression over gzip-6.

    Enforcement & Diagnostic: All codec selection decisions must supply a verifiable hash of the domain corpus and reproducible benchmarking commands executed on actual domain payloads. Unverified synthetic benchmarks trigger diagnostic ERR_SYNTHETIC_BENCHMARK_REJECTED.

    Forbidden Output Behavior: The system is strictly forbidden from accepting vendor claims or generic third-party benchmarks as evidence for production codec configuration.

    3. Reject Unbounded Queue [ADV-UQ-01]

    Vulnerability: Placing unbounded in-memory queues or channels in front of CPU-intensive compression worker pools. When incoming request rates exceed compression throughput, backlogged requests accumulate indefinitely in RAM.

    Adversarial Mechanism: Under peak bursts of 4,200 syncs/sec, unbounded task queues in the ingress proxy buffered 8,500 pending payloads (each 3.8 MB), consuming 32 GB of RAM within 45 seconds and triggering kernel OOM-killer termination of the gateway.

    Enforcement & Diagnostic: Compression pipelines must operate with bounded queue capacity (maximum 50 queued items per worker thread). When queue capacity is reached, callers are shed immediately with

    HTTP 503 Service Unavailable and Retry-After: 3 headers. Attempting to allocate unbounded buffers emits diagnostic ERR_UNBOUNDED_QUEUE_REJECTED.

    Forbidden Output Behavior: The system is strictly forbidden from queueing compression tasks in unbounded memory structures or permitting worker queue depths exceeding configured concurrency quotas.


    Invariants and Contracts

    Canonical Signing Independence Invariant [INV-COMP-01]
      Payload cryptographic signatures and integrity checksums must be computed exclusively
      over the uncompressed canonical JSON bytes. Compression is strictly a transport-layer
      encoding and must never alter signed payload digests.
    
    Content Negotiation Precedence Invariant [INV-COMP-02]
      Ingress proxies must evaluate HTTP `Accept-Encoding` in strict order: `br` (Brotli-5)
      takes precedence for modern clients; if absent or unknown, fall back to `gzip` (gzip-6).
      Raw uncompressed JSON is returned only if client explicitly specifies `Accept-Encoding: identity`.
    
    Bounded Streaming Frame Ceiling [INV-COMP-03]
      Streaming compressors and decompressors must process data in discrete chunks of at most 64 KB.
      Allocating unbounded contiguous memory buffers for payload expansion is strictly prohibited.
    
    Decompression Bomb Ratio Guard [INV-COMP-04]
      Decompressors must continuously monitor the expansion ratio ($\text{BytesOut} / \text{BytesIn}$).
      If total decompressed bytes exceed 32 MB OR instantaneous ratio exceeds 10:1, execution must abort
      immediately with HTTP 413 Payload Too Large and discard all buffered partial bytes.
    

    Explicit Unknowns

    • CPU throttling behavior on 2021 fleet handheld devices when ambient operating temperatures exceed 40°C in outdoor field operations (G-1).
    • Cellular carrier middlebox behavior regarding HTTP Content-Encoding: br header manipulation on 3G network towers in remote regions (G-2).

    Traceability

    ClaimClassificationSourceFreshness
    Peak 4,200 sync requests/secprovidedIngress traffic specificationCurrent
    3.8 MB median uncompressed JSON payloadobservedProduction corpus sampling (BL-3801)2026-09-15
    Incident INC-3820 64 vCPU exhaustionprovidedPost-mortem root cause analysisHistorical
    2021 fleet handheld Brotli incompatibilityobservedMobile device matrix test TR-22012026-09-15
    Brotli-5 server encode p99 <= 45 msobservedBenchmark BM-99122026-09-15
    gzip-6 fallback for legacy handheldsdecidedMarcus Vance & Elena Rostova2026-09-15
    Hard 10x / 32 MB decompression bomb ceilingdecidedArchitectural invariant INV-COMP-042026-09-15
    64 KB streaming chunk frame limitdecidedArchitectural invariant INV-COMP-032026-09-15

    Verification

    GateCommandExitEvidence time
    Corpus Validationpython scripts/verify_corpus_distribution.py --corpus corpus/telemetry_v2_corpus.tar.gz02026-09-15T10:14:22Z
    Codec Benchmarkbash scripts/run_codec_benchmarks.sh --corpus corpus/telemetry_v2_corpus.tar.gz --levels br:5,gzip:602026-09-15T10:18:45Z
    Decompression Bomb Drillpython scripts/test_decompression_limits.py --bomb-ratio 15 --max-bytes 3355443202026-09-15T10:22:10Z
    Bounded Queue Stressbash scripts/stress_compression_queue.sh --concurrency 4200 --queue-limit 5002026-09-15T10:26:30Z

    Reviewer self-check against compression architecture contracts:

    • Workload Model: PASS. Validated against 500-sample production corpus representing real field inspection payloads.
    • Budget Integrity: PASS. Explicit p90 and p99 budgets defined for encode CPU, decode CPU, and wire latency.
    • Bottleneck Analysis: PASS. Network vs CPU bottleneck trade-off curves documented with dynamic quality adaptation.

    Adversarial Defenses: PASS. Rejects average-only targets, ungrounded synthetic benchmarks, and unbounded worker queues.

    • Decompression Safety: PASS. 10x ratio ceiling and 32 MB absolute limit terminate decompression bombs safely.
    • Markdown Purity: PASS. Native Markdown syntax strictly adheres to rule_markdown.md without escaped formatting.

    Open Decisions

    • DEC-COMP-01: Elena Rostova to evaluate whether zstd dictionary compression should be piloted for the 2027 fleet refresh once all 2021 handhelds are retired (Owner: Elena Rostova).

    Next steps

    1. Marcus Vance configures Cloud Ingress Nginx / Envoy proxies with Brotli-5 (brotli_comp_level 5) and gzip-6 (gzip_comp_level 6) content negotiation rules.
    2. Elena Rostova updates mobile client SDK to send Accept-Encoding: br, gzip on 2023+ devices and Accept-Encoding: gzip on 2021 devices.
    3. SRE team deploys Prometheus alerting rules on compression_duration_seconds{quantile="0.99"} (> 45 ms) and compression_decompression_ratio (> 10.0).
    4. Run end-to-end field sync drill across simulated 3G network conditions before production traffic cutover.

    http-payload-compression-contract-design.tsx

    TSX · React component

    Generated

    Example file from a real run - the skill writes it into your workspace.

    Connects securely to your tools. The creator never sees your data.

    What you get

    Define Brotli, Gzip, or Zstd codec parameters for APIsEstablish MIME allowlists and minimum size thresholdsMap compression negotiation and fallback logic for clientsBalance payload size against CPU and memory constraintsEnsure decompression safety and semantic fidelity limits

    About this skill

    What it does

    This skill maps one accepted representation/path into an exact compress/decompress contract. It balances encoded size against producer/consumer CPU, memory, latency, access and compatibility while preserving required semantics and bounding untrusted expansion.

    Use it when

    Use when a known payload/file/object/stream requires a bounded compression choice under measured resource and compatibility constraints.

    For example: “Our field engineers sync job packets over 3G in rural areas. A packet is 4 MB of JSON, sync takes 90 seconds, and half the time it fails and starts over.”

    What you get

    • Compression Spec

    Written as Markdown to <your output folder>/architecture/tasks/<run-id>/compression-design/.

    What it will not do

    Do not use for serialization schema design, media transcoding, archive/backup packaging, encryption/signing, HTTP/CDN/database/storage configuration, one file operation or generic tuning.

    How it works

    1. Check the bottleneck is bytes and not CPU.
    2. Bound exactly which representation and path is being compressed.
    3. Pick the codec against the measured shape of your data.
    4. Fix negotiation and the fallback.
    5. State what compression must not change.
    6. Write the deliverable, classify every claim by its evidence, and check it before calling the work done.

    What's in the package

    Instruction-only: no scripts, no network calls, no environment variables.

    • LICENSE.txt
    • SKILL.md
    • agents/openai.yaml
    • assets/output-template-task.md
    • references/domain-rules.md
    • references/operating-rules.md
    • references/output-contract.md

    How to install

    Works the same in every agent - Claude, Cursor, Codex, Copilot and 20+ more.

    ~30 seconds
    1. 1

      Download the ZIP

      Free skills download straight away. Paid skills unlock right after purchase.

    2. 2

      Unzip into your skills folder

      Every agent reads skills from one folder on your machine. Drop the unzipped folder in there.

    3. 3

      Ask your agent to use it

      Restart the agent if it was already running. It picks the skill up automatically - no config needed.

    Skills folder by agent

    Click the path to copy it. Create the folder if it does not exist yet.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill passes our trust checks below.

    Security scanned

    Passed our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    30-day refund

    Not a fit? Get your money back

    Trust & safety

    Security scanned

    Verified clean 12 days ago

    • Passed all security checks, Safe to install

    Listed12 days ago

    What's inside

    Frequently Asked Questions