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.

Every order in this demo carries two identifiers, and they are not redundant - they answer different questions and cost you different amounts of work.

correlationId is technical correlation. It comes from a W3C traceparent injected by real OpenTelemetry instrumentation in the demo's services. Spider extracts it with nothing configured - the rules ship pre-written, and a fresh install links this chain on its first capture. It reaches HTTP, gRPC, Kafka and PostgreSQL, and it survives the whole asynchronous tail: the order.placed event, payment's reply, notify's ack and the final UPDATE all carry the same one. Trace propagation genuinely works here.

Where it is absent is the interesting part, and it is not only Redis. RESP has nowhere to carry a propagation header, so the two Redis commands have none - that much was expected. But neither do the two requests the customer actually made. The client is not instrumented, which is exactly the situation you are in with any browser, mobile app or third-party caller you do not control.

orderId is business correlation. It is the order UUID, pulled out of wherever it already lives on each hop - a protobuf field, a Redis key, a SQL column, a Kafka record - by the tag rules you saw in the previous step. It costs you ten minutes of configuration. In exchange it reaches all five protocols, including the Redis hop nobody instrumented, and it names the thing your business actually cares about.

Count the calls on the diagram above - one request and its reply is one call. A successful order is 15 calls. The first correlationId covers 9 of them. Four have no correlationId at all - both Redis commands, and both HTTPS requests the customer made. The remaining two belong to a second trace entirely. orderId covers all fifteen. (Those counts are for an order that succeeds; the simulated out-of-stock and payment-declined paths short-circuit and have fewer calls.)

So correlationId is what you get in the first twenty minutes, and orderId is what you get once you have told Spider what your business calls things. The technical one proves the request happened; the business one answers "what happened to this order", which is usually the question that was asked in the first place. Neither makes the argument alone.

That last group is the one to look at, because it does not close with better instrumentation. The two identifiers slice the traffic along different axes: a correlationId groups what followed from one request, while orderId groups everything that ever touched one order, across requests that have nothing technically to do with each other.

The status poll on the diagram is that argument in miniature. The customer asks "where is my order" - a new request, so a new trace id, correctly so - and yet it is unmistakably about the same order. Perfect instrumentation would not merge the two; it would just give the poll a cleaner second trace. The same holds for anything that runs later: a webhook, a nightly reconciliation, a retention sweep. Each arrives with its own trace or none, and the order id is what ties them back together. Batching inverts it - fold a hundred orders into one sync call and that call has exactly one trace id covering all hundred, and only the business identifier still picks out yours.

In the grid, a communication carrying either one gets a link button in the Links column: click for the whole chain in the unified view, shift-click for its sequence diagram. Which tags earn that button is a setting, so you can point it at your own business identifier - and because it is a display setting rather than a capture setting, traffic captured months ago lights up immediately.

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.