Privacy Is No Longer a Requirement. It's an Architectural Constraint

Every engineering team claims privacy comes first, but their architectures rarely reflect that. Privacy and accessibility often appear as afterthoughts in a checklist that only gets reviewed late in development. Despite proclaiming them non-negotiable, systems are frequently built that treat these principles as negotiable, failing to adequately address them until it's too late.

As someone who has spent over two decades building systems serving billions of users, I've learned the hard way that privacy and accessibility aren't just policies to enforce — they're architectural constraints that must be designed into the system from the ground up. Privacy becomes exponentially more challenging as scale increases.

At a small scale, one team can oversee the entire data flow, understanding where data is collected, where it goes, and who has access to it. However, at a large scale, this mental model breaks down. With dozens of services emitting billions of events daily, every new pipeline creates additional opportunities for personal data to leak.

It's not typically due to a breach, but rather through well-meaning engineers inadvertently including too much data in a pipeline. Moreover, assuming location data can be easily anonymized by removing names is flawed. Human mobility patterns, such as home, work, and daily routes, uniquely identify individuals with remarkable accuracy.

Coarsening location data compromises the very product that relies on it, and traditional anonymity guarantees become ineffective when dealing with sparse, high-dimensional data like movement patterns. Thus, anonymizing location data isn't just an afterthought; it's an architectural decision about what data should never be collected in the first place.

Similarly, deletion becomes a complex distributed-systems problem rather than a simple operation. Deleting user data requires propagating the action through backups, caches, search indexes, derived aggregates, replicas, and any models trained on that data. While deleting a single record may seem straightforward, it's a monumental task if not designed for from the outset.

Accessibility bugs often slip through automated testing because the test oracles assert the wrong contract. For instance, if a button loses its accessibility label during a refactor, functional tests may still pass, as the button renders, responds to taps, and changes state as expected. However, users relying on screen readers will experience a significant issue — the button now announces nothing, making it effectively unusable.

These accessibility regressions are not recognized by automated tests because they focus on behavior rather than the semantics of the user experience. To address this, accessibility needs to be treated as a first-class engineering concern, asserting the accessibility tree rather than just the UI state. Trust is another architectural property, not merely a feature or policy.

It's built over time through thousands of small defaults. On-device processing exemplifies trust as architecture. By moving computation to the device, sensitive data never reaches the server, reducing the risk of exposure. However, this decision impacts the entire system — model size, synchronization strategy, logging practices, and failure handling.

It cannot be retrofitted onto an existing architecture; it must be designed from the beginning. The trust accumulated through these architectural decisions is as fragile as it is valuable, eroding gradually through the accumulation of small, seemingly insignificant data leaks. To automate the enforcement of critical architectural constraints, we must focus on invariants that are easy to check but catastrophic to overlook.

Data minimization is a prime example. Instead of relying on code reviews to catch over-collected fields, we should make data minimization a build-time invariant. By ensuring telemetry events can only carry fields declared in an allowlist, the build process will fail if an undeclared field is included. This approach transforms the check from a mere policy to an enforceable rule within the build process.

The same principle applies to accessibility and location precision. By automating checks for the presence of accessibility labels, the correct measurement of contrast ratios, proper focus order, dynamic-type reflow, and screen-reader labeling, we ensure these aspects are never overlooked. Similarly, asserting that coordinates are fuzzed below a certain threshold before being persisted prevents location data from being overly precise.

Automation catches violations that judgment alone cannot identify. However, it's crucial to recognize that automation cannot determine whether a new feature's data collection is proportionate. Human oversight remains essential to evaluate the necessity and proportionality of data collection. In conclusion, privacy and accessibility are not optional features to bolt onto a system but fundamental architectural constraints that must be designed into the system from the ground up.

By integrating privacy and accessibility considerations into the design process, systems can be built that protect user data and ensure equitable access for all users.