Watch Spider decrypt live traffic across 5 protocols

A synthetic e-commerce store runs 24/7 in the demo environment. Real orders flow through it continuously, exercising the whole backend stack.

Every order you see placed here is about to travel through six services and five protocols - encrypted end to end.

Six polyglot services sit behind the shop - three in Go (order, stock, catalog) and three in Node.js (storefront, payment, notify) - plus Redis, PostgreSQL and a Redpanda (Kafka) broker.

storefront is the HTTPS entry point; order orchestrates the purchase over gRPC; stock holds the reservation in Redis; order persists to PostgreSQL and publishes an order.placed event to Redpanda, which payment and notify consume asynchronously. Normally, following one order across all of this means stitching together logs from every service.

The whisperer is injected into a running pod as an ephemeral debug container - a tiny sidecar that Kubernetes attaches on demand. It shares the pod's network namespace and sniffs that pod's traffic. No image rebuild, no permanent sidecar, no code change.

Gocipher runs as a DaemonSet - one instance per node - and hooks OpenSSL through eBPF uprobes to extract TLS master secrets. Spider uses those keys to decrypt the captured packets after the fact.

This is Spider's own map of the running demo - every component it has discovered, grouped by Kubernetes namespace. The whole shop is here: storefront, catalog, order, stock, payment and notify, plus Redis, PostgreSQL and the Redpanda broker, the Traefik ingress, and the bot generating traffic.

The services drawn in pink are the ones a whisperer is attached to. Spider taps the application pods - not the datastores, not the broker - and still sees both sides of every conversation, which is all it needs to reconstruct the full cross-service story.

Every capture is a TCP session, and Spider keeps the whole thing. Here is one between the order service and postgres:5432 - 69 packets over 39 seconds, the full pipe, downloadable as raw PCAP.

Spider identifies the handshake - TLS 1.3, cipher TLS_AES_256_GCM_SHA384 - and reports what it parsed (TLS and PostgreSQL, both COMPLETED). Open the Details tab and you see exactly what crossed the wire: encrypted TLS records, pure ciphertext.

Now switch to Content with the PostgreSQL decoder. Spider peels back each TLS record and decodes the Postgres protocol underneath - the Bind and Execute messages, the prepared statement, and the real parameters: the order UUID, sku-webcam, the buyer's email, the PLACED status. That is the headline claim, proven end to end - encrypted on the wire, readable in Spider, with nothing instrumented.

A single order exercises all five protocols. storefront takes the HTTPS request and calls order over gRPC (PlaceOrder). order calls stock over gRPC (Reserve), which holds the reservation in Redis. order writes the row to PostgreSQL and produces an order.placed event to Redpanda (Kafka).

payment consumes that event asynchronously and acks back to order over HTTP, which updates PostgreSQL. Every hop is TLS-encrypted; Spider captures all of it from the network and reassembles the whole path.

The diagram above is the design. This one is real: Spider drew it from the decrypted packets of one specific order - the same eight participants, every gRPC, Redis, PostgreSQL, Kafka and HTTP hop, with real timestamps and durations down to the millisecond.

Nothing was instrumented to produce it. Spider reconstructed the entire cross-protocol sequence - including the asynchronous payment.completed round-trip - purely from captured traffic.

Spider's grid lists every captured call that belongs to one order, side by side, whatever the protocol: the HTTP POST /api/orders, the gRPC PlaceOrder and Reserve, the Redis HSET/EXPIRE, the PostgreSQL INSERT/SELECT/UPDATE, the Kafkaorder.placed and payment.completed.

Each row carries a readable template name (Place order, Reserve stock, Create order…), the real request, sizes, status and duration - and the extracted orderId on the right, the same value on every row. That shared ID is what ties the list together.

gRPC is binary and TLS-encrypted - normally a black box. Click any call and Spider shows the whole thing: the method (demo.order.v1.OrderService/PlaceOrder), the timing, request and response sizes, status, and the client and server pods.

Flip on Transcoded in the Request tab and the raw protobuf becomes readable JSON - the orderId, the productId, the quantity, the customer's email. Spider decrypted the packets, reassembled the gRPC frames and decoded the protobuf for you.

This is where the linking comes from. Each whisperer carries a parsing configuration. For PostgreSQL, Spider is given the query templates that matter - Create order is ^INSERT INTO orders, Read order status is ^SELECT status FROM orders - so raw SQL gets a human name.

More importantly, a request tag maps orderId to the orders.id column. Spider parses the query, understands which field is which, and extracts the value - and does the same across the other protocols, so the one order ID is recovered wherever it travels: HTTP body, gRPC message, Redis key, SQL row, Kafka event.

The extracted order ID is a UUID - correct, but not friendly. A small tag-enrichment plugin, the Demo order resolver, loaded in Spider's settings, turns eachorderId tag into something a human reads: here, "2026-07-06 HD Webcam ×3", built from the order's date and product.

The plugin also carries a link back to the store - so the tag is not just a label, it is a doorway to the business system.

Click the enriched tag and Spider sends you straight to that order in the store's own back office - the Spider Tech Store order page, showing the same order: ACKNOWLEDGED, the customer, the product, the total.

That is the whole promise in one gesture. You started from raw, encrypted packets on the wire and landed on the business record they represent - no instrumentation anywhere, just capture, decode, and the identifiers already living in your data.