The concept

In Data Mesh [1] a data product is an architecture quantum: the smallest independently deployable unit carrying everything it needs, from transformation code over the data itself and its metadata to infrastructure specs and policy configuration. The framing throughout the book is that a data product is active. It serves, governs, and maintains its own data, where files and tables are passive.

Each data product's runtime is decorated by the sidecar: the same pattern service meshes use (an Envoy next to every service), repurposed for analytical data. The sidecar is the home of everything which should be identical across all data products: policy and access enforcement, audit logging, handling of personally identifiable information (PII), publication of service level objectives (SLOs), discovery endpoints. The rule of thumb is clean: Domain-specific behaviour lives in the product, domain-agnostic behaviour lives in the sidecar.

As a conceptual model this is good. It names a real recurring triad (security, quality, audit) and explains why it recurs together on every data product. So the natural architect's reflex kicks in: Where does the sidecar live in our repository? Which directory, which deployable, which team owns it?

I spent a while on that question and ended up with nowhere – and it must stay nowhere.

No reference implementation

The book itself flags this. Dehghani marks the data quantum and its computational container as experimental concepts with custom implementations. There is no widely adopted reference implementation of a data-product sidecar, and she explicitly leaves the physical form open: It may be a shared library, an accompanying process, or a logical grouping enforced by the platform. In most real deployments I could find, the sidecar exists only on the slide deck.

When I mapped our own cross-cutting concerns, each of them already was in a sensible place:

• Data-quality checks run inside the pipeline, as dbt tests and Great Expectations suites, next to the transformations they check.

• Access and consent enforcement live at the serving gateway, the single door through which data leaves the platform.

• Audit and observability live in the monitoring stack.

Collecting these into a deployed per-product sidecar process would not make any of them better. It would make most of them worse: quality checks separated from the transformations they validate, consent enforcement duplicated out of the one place which is currently impossible to bypass. The behaviours are cross-cutting by definition, and this is precisely why they resist being bundled into a single box.

The axis that organizes the code

More useful was asking what problem I was trying to solve by "placing" the sidecar. The question decomposed into a different one: Which parts of each concern are platform (reusable for any tenant running this stack) and which are tenant-specific (this university's policies, retention rules, consent texts)?

Every sidecar-ish concern splits cleanly along that axis. PII enforcement code is platform, the PII categories and tagged fields are tenant policy. The consent mechanism is platform, the consent texts and processes are tenant. Audit plumbing is platform, what is audited and retained for how long is tenant policy. The rule which fell out of this:

The platform may read declarative policy from the tenant side, but never imports code from it.

This rule tells me where every file goes and which direction dependencies point. "Sidecar" told me neither.

Where the concept is still useful

So is the sidecar useless? No. It is useful in two places, both of them vocabulary:

1. Communication. In diagrams and onboarding for anyone with a data-mesh background, "the sidecar concerns" is the fastest way to say "security, audit, quality, SLOs – the stuff which must look identical on every data product."

2. A design checklist. When adding any new capability, the question "would this go in the sidecar or in the product?", mesh-uniform or product-specific, forces the right call before the second question, "platform or tenant?", places the code.

In an earlier post I argued that cross-cutting perspectives are lenses you run over structural views, not views of their own. The sidecar is the same insight in data-mesh terms: the logical anchor the security, quality, and audit perspectives attach to. Reifying it into a deployable would be the structural version of drawing "the security diagram".

Conclusion

Architecture concepts come in two kinds, and they do not announce which kind they are. Structural ones tell you where code goes and which way dependencies point, vocabulary compresses a recurring pattern into a word. The expensive mistake is building a component because the literature has a name for one. My test is unglamorous: Does this concept, made physical, make anyone's work easier this quarter? For the sidecar the answer was no on every count.

References

1

Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly. Data product as architecture quantum; sidecar and computational container as (explicitly experimental) carriers of cross-cutting, mesh-uniform behaviour.