Prateek Chawla and the Art of Stopping Bad Data at the Door

Bad data has excellent manners. It rarely kicks down the door. It arrives quietly, dressed like a valid row, takes a seat in a pipeline and waits for someone to trust it. By the time a broken number reaches a dashboard, it may already have acquired the authority of a chart. Prateek Chawla has spent much of his career making that journey shorter. His preferred intervention is practical, almost domestic: catch the problem near the entrance, before it wanders through the whole house.

Chawla is a founding and principal engineer at Monte Carlo, the San Francisco data observability company. He joined in 2019, when a startup title was less a boundary than a dare. He arrived with a background in backend and cloud engineering and was handed a blanker problem: build the company's data platform. So he became a data engineer as well. Snowflake, Looker and dbt entered the picture. Airflow and Spark joined the cast. The architecture grew in public, with the useful indignities of any early system: decisions that worked, decisions that had to be revisited and tools asked to do one more thing than their brochures had promised.

A career built around the early warning

Before Monte Carlo, Chawla was a technical lead at Barracuda Networks, working on email fraud prevention. The object changed when he moved into data infrastructure, but the instinct did not. Both jobs concern systems that look ordinary until a dangerous thing passes through them. Both reward early detection. Both turn trust from a pleasant word into a sequence of technical decisions.

He had finished a B.S. in Computer Science and Engineering at the University of California, Santa Cruz, graduating summa cum laude in 2016. Barracuda recognized him with a peer award in 2015 and a Security MVP honor in 2017. By 2019 he had also earned a student pilot certificate. Flying sits on his list of interests beside Broadway shows, books and exploring new places. It is tempting to make aviation carry a grand metaphor, but the documented detail is interesting enough: an engineer whose public work emphasizes layered safeguards also chose to learn his way around a cockpit.

“When it comes to the data engineer life, to be in the code is to exist.”Prateek Chawla

That line explains a good deal of his product argument. A handsome interface can be helpful, but engineers also need the freedom to automate, compose and extend. Chawla's writing about Monte Carlo's developer tools is therefore a tour through escape hatches that are actually front doors: an API, a Python SDK, a command-line interface, monitors expressed as code and webhooks that let one system speak to another. The point is not to keep users staring at code for its own sake. It is to let them work in the environment where they are fastest.

The little switch with a large responsibility

His most memorable public analogy arrived through Apache Airflow. Testing is good at catching failures that an engineer has imagined in advance. Production has a larger imagination. Chawla proposed borrowing the circuit breaker from DevOps and electrical systems: when monitoring discovers unsafe data, interrupt the Airflow workflow before the problem cascades through dependent pipelines.

The idea is appealing because it gives data quality a physical verb. Do not merely report the incident. Break the circuit. Yet Chawla did not sell the operator as magic. A breaker belongs beside testing, monitoring, lineage and alerting. It needs careful placement. Trigger it carelessly and a defensive mechanism can become another source of downtime. His warning supplied the missing half of the metaphor: power is useful precisely because switches deserve respect.

The talk made Chawla visible beyond his company. In another session, he walked data and machine-learning engineers through reliability across a lakehouse, including PySpark monitoring and the role of Delta Lake. At dbt's Coalesce, he returned to Monte Carlo's own history and described the data platform he had built from scratch. This was not an immaculate case study delivered from a distant stage. He spoke as the backend engineer who had been obliged to wear the data-engineering hat, then discovered that it fit.

From startup flexibility to enterprise reality

As Monte Carlo's customers grew larger, the engineering puzzle expanded. A startup can choose a fashionable stack. An established enterprise may have several clouds, warehouses and lakehouses, a database on premises, strict rules about inbound traffic and a security team that regards “just open a port” as a cry for help. Chawla's later work has focused on making observability inhabit that reality.

“No two companies are ever quite the same.”Prateek Chawla

The sentence looks modest. Architecturally, it is expensive. Monte Carlo developed choices about where a collection agent runs, where sampled data is stored and where credentials remain. Its cloud deployment can be fully managed. Its hybrid arrangements can leave an agent and data store in the customer's environment. A newer generic agent runs wherever Docker runs and communicates outward, without demanding an inbound opening. The elegant diagram gave way to a menu, because customers already had kitchens.

Chawla has described this as customer-driven engineering. The phrase can become wallpaper in corporate writing, but here it names specific concessions to how people operate: AWS, Google Cloud and Azure; private connectivity; customer-hosted secrets; proxies; custom certificates; identity controls; granular ingestion rules. Flexibility is not a mood. It is a backlog.

The agent before the agents

By 2026, the word “agent” had become unavoidable. Monte Carlo already used it for the software component connecting customer systems to its platform. Chawla acknowledged the collision with a dry aside: “We named our collection agent before ‘AI agent’ became the entire industry's obsession.” The company was not changing the name yet.

Behind the joke was a more consequential shift. Chawla described an integration framework assembled from reusable building blocks. Native connectors could work alongside APIs for pushed metadata and custom SQL connectors. A conversation with Claude could produce scaffolding, query templates, tests and a deployable image for an unfamiliar system. The result was intended to behave like a regular integration, with the same monitoring, alerting and lineage rather than a clever demonstration stranded at the edge of the product.

This is the long arc of Chawla's work in miniature. In 2019, he adapted himself to the missing job, becoming the data engineer the startup needed. In 2026, the platform adapted itself to missing connectors, creating a route for unusual enterprise systems to join. The constant is not a particular tool. It is the refusal to pretend variety will disappear.

Complaints are a form of telemetry

Chawla once offered a nicely blunt observation about expanding data teams: “The more people look at something, the more likely they'll complain about them.” The grammar is casual; the operating lesson is sharp. More users create more scrutiny. More scrutiny finds more failure. A platform trusted by a handful of specialists faces a different life when hundreds of people and consequential decisions depend on it.

The engineer's response could be defensiveness. Chawla's public record suggests a more useful response: turn the complaint into architecture. A support request becomes an API. A security objection becomes a deployment mode. An unknown data failure becomes a monitor attached to a breaker. A source outside the integration catalog becomes a composable connector. The person raising the problem may think they are describing an exception. The engineer can choose to hear a pattern.

That is why his story is less about one dramatic invention than about a disciplined sequence of accommodations. He has worked at the layer where software meets the awkward facts of use: credentials, retries, network boundaries, inconsistent systems and humans who would rather fix a problem in five minutes than file a ticket. His tools are technical, but his recurring subject is trust. Trust that the number is sound. Trust that the platform will fit. Trust that when something breaks, the trouble will not be allowed to stroll all the way to the boardroom.

Bad data will continue to have good manners. Fortunately, Chawla keeps working on the lock, the alarm and, when necessary, the switch.