Data Engineering at Cloudflare

The employer trade at Cloudflare is a familiar one for network-security companies: technically demanding work in a domain that matters, against a backdrop of visible internal friction. A 3.3 Glassdoor rating toward the bottom of the pack is hard to square with the company's public reputation as a desirable place to work, and Blind sentiment is mixed. Engineers here are neutral and roughly flat, which suggests the gap between what Cloudflare promises in recruiting and what the day-to-day delivers has widened recently. Pay, at least, does not appear to be the primary complaint: the salary pool is above other Technology companies. The honest read is that you get a hard problem domain and competitive pay, and you give up some cultural stability and management consistency in return. That trade works for some engineers and doesn't for others.

Cloudflare has 1 tracked layoff in the past 12 months, the most recent in May 2026, and the 30-day layoff risk is low, so a sudden workforce event is not the immediate concern. The 1 executive departure in the past year alongside the declining happiness trend is worth watching: leadership churn and engineer sentiment moving in the same direction tends to signal organizational restructuring more than simple growing pains. Hiring is active, with 12 open data engineering roles and Austin as the top hiring market, which suggests investment in data infrastructure is continuing. Over the next twelve months the most likely scenario for someone joining now is a period of team formation and shifting priorities as the organization works through whatever is driving that sentiment decline; new hires should expect some ambiguity in ownership and roadmap in the near term.

Cloudflare's core data problem is network-scale telemetry: the company processes over 50 million HTTP requests per second across its global edge network, and every request generates logs, security signals, and performance metrics that have to land somewhere useful. Data engineers here are building and owning the pipelines that move that volume from edge nodes into something analysts and product teams can act on. The stack signal, Kubernetes, Docker and Kafka, tells you a lot: Kafka for ingestion at edge velocity, Kubernetes and Docker for containerized pipeline workloads that need to run consistently across a distributed fleet. The languages, SQL, Python and JavaScript, put SQL and Python at the center of transformation work with JavaScript showing up from edge-side data collection. This is infrastructure-adjacent data engineering, where the pipelines run close to the network layer and reliability SLAs are tight.