Google account bans, Zanzibar, and mechanism design

There is a common narrative whenever Google deletes someone's entire 15-year digital life over a minor API violation, perfectly encapsulated by a recent top comment on Hacker News defending the Antigravity API bans by arguing that isolating an API suspension without locking the whole auth graph would be a distributed systems nightmare. This is the dominant cocktail-party systems engineering take for why these nuclear-option account bans happen, largely because it provides a comforting technical excuse for a brutal organizational reality. The argument supposes that a trillion-dollar company's architecture is simply too brittle to surgically decouple an offending developer project from a core consumer email account without everything breaking, turning the collateral damage of losing a decade of family photos into an unfortunate technical necessity rather than a predictable byproduct of corporate mechanism design.

That assumption collapses completely when mapped against the actual technical infrastructure.

The recent wave of bans, documented by Gergely Orosz regarding the Antigravity TOS, saw users permanently locked out of their entire Google ecosystem—Gmail, Drive, Photos, Android backups—for Terms of Service violations on a specific developer API. When we look at these incidents, we see a severe disconnect between the stated reason for the suspension and the blast radius of the punishment. To understand why the distributed systems defense falls apart under scrutiny, we have to ignore the cocktail-party consensus and look at the mathematical reality of how Google actually stores permissions.

According to Google's own 2019 USENIX ATC paper on Zanzibar, their consistent, global authorization system, permissions are stored as uniform relation tuples. The architecture handles trillions of access control lists at sub-10ms latency. Rather than acting as a precarious operation requiring global locks across massive SQL databases, an authorization check in this environment simply evaluates straightforward tuples taking the form object#relation@user.

To give a sense of scale, the paper notes that Zanzibar processes over 10,000,000 client requests per second globally, while maintaining a 99.9% availability SLA. The entire system is built on top of Spanner to avoid exactly the kind of monolithic lock contention that the Hacker News commenter assumes is happening. If we write out a simplified cartoon model of what a user's permissions look like in Zanzibar, it looks something like this:

// Core account services
gmail#access@user:12345
drive#read_write@user:12345
photos#backup@user:12345

// Hobbyist API access
antigravity_api#execute@user:12345

Because Zanzibar provides a highly granular data model explicitly built to decouple global identity from specific service logic, suspending a user from a specific API while retaining their Gmail access is functionally identical to removing a single edge in a graph. If you look at the P99 latency graphs in Section 5 of the Zanzibar paper, evaluating a direct relationship takes less than 2ms. The system scales by pre-computing index tables, meaning that severing one edge of the graph—like an API permission—does not cascade into a blocking lock for the rest of the user's profile. The operation to revoke access to the Antigravity API is an O(1) deletion of the antigravity_api#execute@user:12345 tuple. The system natively supports this level of granularity because it was designed from the ground up to evaluate deeply nested group memberships and cross-service permissions without choking under the weight of billions of daily active users.

The claim that an isolated suspension would require locking the whole auth graph demonstrates a fundamental misunderstanding of how Zanzibar scales, which makes sense given how rarely people interact with authorization at this magnitude, but it remains structurally untrue. Google engineered this system specifically so that one service's state does not mandate a global lock on the entire identity tree.

People who recognize that the technical defense is hollow often retreat to a legal defense, assuming that Google is bound by some overarching compliance requirement that forces a blanket ban whenever a user breaks the rules of any subsidiary service. But reading the actual text of the Google Terms of Service, the policy explicitly delineates between suspending an individual service and terminating a whole account. They already retain the legal and structural framework for fine-grained enforcement. When a user repeatedly uploads copyrighted material to YouTube, Google disables the specific channel instead of systematically purging the user's Google Docs. Given the choice between a random internet comment claiming that legal compliance necessitates burning down the whole account and the actual, published terms of service outlining granular suspensions, I'm going to side with the published text.

Figuring out the technical implementation or the legal framework is trivial. The actual root cause of these blanket suspensions requires stepping out of the codebase and looking at the incentive structure of a Trust & Safety team trying to secure a promotion. In Praveen Seshadri's insider observations on Google's promo-driven culture, The maze is in the mouse, he details how teams locally optimize for whatever metrics the promotion committees value, regardless of the holistic impact on the product or the end user. (I'm not going to dive into the exact historical baggage of how promo committees calibrate impact scores here, which would easily double the length of this post, but the short version is that maintenance and nuance are fundamentally invisible to executive leadership).

Imagine the mechanism design problem facing a Trust & Safety Product Manager. To build a successful L6 promo packet, the PM needs to demonstrate measurable impact, typically evaluated on zero-sum metrics like the total volume of abuse vectors closed or the raw number of incidents mitigated. If we expect this PM to voluntarily delay their launch by six months to coordinate a nuanced, cross-service suspension protocol that carefully quarantines the offending developer project while leaving the user's primary email intact, we have to assume that the promotion committee will actively reward them for prioritizing the end-user experience over raw mitigation velocity.

They don't.

Resolving technical constraints is easy compared to resolving organizational rot. The core deception embedded in the distributed systems nightmare argument is the pretense that dropping a database row is somehow more difficult than fighting an entrenched promotion culture.

Building a granular suspension system means the PM has to coordinate across multiple product areas, negotiate with the frontend teams for nuanced error messaging, and build complex recovery and appeal workflows. (If you've never worked at a hyperscaler, it's hard to overstate how much of a tire fire it is to get sign-off from fourteen different stakeholders just to modify an interface, which can easily stall a project indefinitely). The PM is looking at spending multiple quarters of engineering time to achieve the exact same reduction in the core abuse metric. Furthermore, none of the stakeholders who would have to sign off on a streamlined, granular appeals process care about the API team's metrics, meaning the project will constantly be de-prioritized.

Alternatively, the PM can leverage the existing nuclear option: banning the entire account identifier at the root identity layer.

From a mechanism design point of view, the system prices the collateral destruction of a user's 15-year Gmail history as an externality with a cost of exactly $0.00. Because Google has functional monopoly lock-in for consumer email, and because non-enterprise users have absolutely no viable customer support recourse, the churn caused by these bans does not negatively impact the PM's metrics. The user cannot call a representative, the media rarely picks up individual complaints unless the user is highly visible on social media (in which case the PR team will manually un-ban them via a backchannel, completely bypassing the automated systems), and the overarching corporation does not penalize the Trust & Safety team for false positives as long as the macro-level abuse numbers go down.

If we do the math on the local optimization, the choice is entirely rational. Let's say the PM is evaluated purely on the formula total_abuse_stopped / engineering_weeks_spent. The nuclear option yields maximum abuse mitigation for approximately 0 additional engineering weeks, because the global ban tooling already exists and has since the early days of Google Accounts. The surgical option yields the exact same abuse mitigation, but requires dozens of engineering weeks of cross-team coordination. If a PM allocates 25 engineering weeks to build a decoupled API revocation flow, they have generated 0 additional units of mitigated abuse compared to the baseline global ban.

The return on investment for building a granular suspension system is mathematically zero, or even negative, because time spent building humane error states is time not spent launching a new machine learning model to automatically flag more users, which is the kind of bullet point that actually secures an L6 promotion. You'd basically be asking employees to set giant piles of money on fire by intentionally tanking their own performance reviews to save a few users from an automated ban.

The online ecosystem has a deep tendency to assume good intent or attribute catastrophic user outcomes to a mysterious technical glitch in distributed systems, operating under the assumption that because burning a user's data harms the company's long-term brand reputation, the failure must be an unavoidable technical limitation. But the people running the infrastructure simply calculated that preserving an individual's data yields a negative return on engineering hours.

If you ask someone, abstractly, if Google wants to burn a user's 15-year email history to the ground because they misconfigured a hobbyist API, they'd probably tell you no. But insofar as a mega-corp can be said to want anything, it wants what it incentivizes. As long as a PM's L6 promo packet measures 'abuse vectors closed' and prices 'collateral user destruction' at exactly $0.00, the system is operating exactly as designed.