Case Studies

Spider Analyzer was built inside Flowbird, a payments infrastructure company, to solve problems its own engineering team kept running into. These are real incidents from Flowbird's production and test systems - the kind of thing Spider was built to make visible.

What it gets used for

• System discovery and understanding how services actually talk to each other
• Root-cause analysis, third-party integration checks, and network troubleshooting
• Post-deployment sanity checks and access-rights debugging across a request's full fan-out
• Performance and concurrency analysis without adding instrumentation
• Retracing security incidents - what was accessed, and what wasn't

Real incidents

A parallel call nobody knew about (2018)

A Flowbird microservice started returning unexplained, unreproducible answers. Spider's sequence-diagram view showed another call being made in parallel to a different API on the same service replica - and that API's parameter was declared as a global, silently affecting the first call. What would have taken weeks to track down by reasoning about the code took under an hour with the traffic in front of us.

A one-millisecond clock drift (2021)

A random share of calls in Flowbird production started failing with 403 Not authorized, while identical calls moments before or after succeeded. Weeks of investigation went nowhere. Spider was off at the time; once reinstalled, it found the cause in under an hour: the IAM server's clock was drifting a millisecond or two ahead of the application servers every hour, so tokens generated right at a second boundary carried an nbf ("not before") claim that hadn't taken effect yet on the server that received them.

An NGINX cache mixing up two auth methods (2022)

On Flowbird's test platform, a process was making requests with a token it had no way of knowing about. Spider traced it to NGINX's forward-auth cache: an earlier request had authenticated with both a certificate and a token from two different users - a genuine bug in the calling code - and NGINX then served that cached result to a later request that only presented one of the two. Two separate bugs, found only because the traffic itself was visible.

Validating a Swarm-to-Kubernetes migration (2023)

Migrating from Docker Swarm to Kubernetes, Flowbird needed confidence in the new cluster before cutting traffic over. Instead of relying solely on the regression suite, they replayed live production requests onto the new cluster within seconds of the originals, rewriting URLs in the payload on the fly to match the new environment - and used Spider on the new cluster to confirm every replayed request actually succeeded. Spider then monitored the gradual traffic shift, ready to flag the first sign of trouble.

Cloning a protocol before a vendor shutdown (2024)

When an IoT connectivity vendor announced it was shutting down, Flowbird had thousands of devices depending on it, with no realistic path to re-flash them all in time. Using Spider's plugin system, the team built a decoder for the vendor's specific MQTT variant, captured device traffic via a man-in-the-middle position, and used it to reverse-engineer the protocol well enough to build a drop-in replacement service - validating it against real device traffic before cutting over, and monitoring the live cutover with Spider once it shipped.

Proving it wasn't our system (year undated)

A customer reported 15-second response times when nobody else was seeing slowness. Spider showed every individual request answered in under 500ms - the same requests the customer was measuring as slow. The actual cause was on their end: a retry loop, amplified by an infrastructure misconfiguration, meant a single logical request triggered tens or hundreds of real ones, and their monitoring measured from the first attempt to the final answer. Spider's timeline made the distinction unambiguous.

Isolating an attacker in production (2025)

Flowbird noticed unexpected usage patterns in production on several occasions. Spider traced the calls back to their root, which was enough to isolate the source, confirm exactly what had been accessed, and establish that no critical data had been reached.