Short answer: treat support logs as personal-data records with a deletion clock, a cost owner, and an export path before you compare hosted services. A GDPR-friendly EU logging design stores a short-lived event index, keeps payloads deliberately sparse, and can prove that one user's records were removed without deleting an entire tenant.
The question is not which hosted log service has the nicest search screen. It is whether your app can answer three awkward questions on a Tuesday afternoon: what did we retain for this customer, who paid for those bytes, and how do we remove or export them without breaking an incident investigation?
How do EU support logs become deletion records?
For a support application rolling out a new pricing rule behind a flag, the dominant term is usually retained volume, not the number of dashboards. A useful first approximation is:
monthly retained bytes = events per request x requests per day x average event bytes x retention days
That equation changes when a support agent adds a transcript, a stack trace, or a high-cardinality label such as conversation_id. Ten small JSON fields repeated on every retry can cost more than a carefully sampled request trace. I count labels as cardinality, and cardinality as future index work; the bill is only the visible part.
Keep the pricing experiment's decision fields (rule_id, flag_variant, region, and a hashed account key) in every event. Keep the transcript out of the default event. Put a reference to an encrypted object in a separate store with a shorter access path, or omit it entirely when the support workflow does not need replay.
Retention is a policy, not a storage setting. For example, seven days of searchable request events can support a rollout review, while a 30-day aggregate can preserve cost attribution without preserving message text. Your mileage may vary: the right period depends on a documented purpose, legal basis, and incident response target.
The catch is that a shorter window increases the chance that a late report arrives after the evidence is gone. That is a real operational cost, and it belongs in the decision record beside the storage estimate.
How can a GDPR-friendly app logging design compare hosted services?
Start with a stable subject key that is separate from an email address. Hashing an email is not automatic anonymisation if the input can be guessed; a keyed, rotated identifier plus an access-controlled mapping is easier to reason about. Every event should carry a tenant scope and the subject key only when the purpose requires it.
Deletion then becomes a bounded workflow. Mark the subject as pending, stop new writes for that subject, remove rows from the hot index, expire object references, and record an audit receipt that contains no deleted payload. The receipt can include a request id, policy version, and completion timestamp. It should not become a second copy of the personal data.
Export is the mirror image. Produce newline-delimited JSON with a schema version, event timestamp, purpose, and source system. Sign the archive, give it a short expiry, and deliver it through an authenticated channel. Do not expose a raw query endpoint to a support agent; that turns a compliance feature into an enumeration risk.
The control plane can expose deletion and export operations behind your identity system; the important contract is idempotency, scope, and an auditable receipt. For event ingestion, a standards-shaped endpoint is enough to illustrate the boundary:
curl -X POST https://logs.example.eu/v1/logs/ingest \
-H 'Authorization: Bearer <token>' \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: privacy-receipt-s_7f31-20260821' \
-d '{"schema":"privacy.event.v1","tenant_id":"acme-support","subject_key":"s_7f31","purpose":"deletion_receipt","status":"completed"}'
The implementation must make retries idempotent. A second delete request should return the same receipt, not resurrect data or create a new chargeable scan. Test this with a fixture containing duplicate retries, a rotated subject key, and an event that is already past retention.
For ingestion, send an idempotency key and retry only transient responses. On 429, honor Retry-After with bounded exponential backoff; otherwise a privacy queue can amplify its own load.
How do retries and samples alter failure handling?
Use two paths. The hot path contains a narrow, indexed envelope: timestamp, service, severity, tenant, flag variant, and a correlation id. The cold path contains sampled payloads or aggregates. A policy engine decides which fields may cross from hot to cold, and a scheduled job enforces expiry in both stores.
Sampling needs a declared error budget. If five percent of checkout requests are retained, retain 100 percent of pricing-rule decisions and deletion receipts; otherwise the experiment's cost attribution becomes guesswork. Tail sampling is helpful when a request ends in an error, but it can increase buffering and operational complexity. Head sampling is cheaper to operate and can miss rare failures. Neither choice removes the need for a retention ledger.
A relational index works for modest volumes and transactional deletion. Columnar storage is useful for long aggregates and scans; ClickHouse documents the trade-offs of analytical storage and compression in its architecture guidance. The boundary is important: do not put mutable personal records in an append-only analytical table and assume a later filter is equivalent to erasure.
For Node.js, emit a versioned envelope at the application boundary and redact before serialization. A small example keeps the pricing context while dropping message content:
curl -X POST https://collector.example.eu/v1/logs/ingest \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: pricing-decision-acme-001' \
-d '{"schema":"support.event.v2","kind":"pricing_decision","tenant_id":"acme-support","subject_key":"s_7f31","flag_variant":"new-rule","rule_id":"price-2026-08","region":"eu-west","message":"redacted"}'
The word “redacted” is not a substitute for redaction. Verify at the serializer boundary that the original text never enters the event object, and sample the wire output in tests.
What evidence should a hosted service evaluation require?
Compare control behavior, not feature checkboxes. Ask each provider for the region of processing, subprocessor list, deletion semantics for indexed data and archives, export format, API authentication, rate limits, and evidence that retention applies to backups. A service may offer an EU region while support metadata or backups follow a different path; the contract and data-processing agreement settle that question.
I use a small scorecard during procurement:
| Control | Evidence to request | Failure mode if vague |
|---|---|---|
| EU processing | Region statement and DPA | Data leaves the intended boundary |
| User deletion | API semantics, receipt, backup policy | “Deleted” data remains recoverable |
| Export | NDJSON/CSV schema and pagination | Access request becomes a manual query |
| Retention | Per-stream TTL and purge timing | Test data accumulates indefinitely |
| Cost attribution | Tenant and variant dimensions | One team pays for another team’s noise |
Any hosted service is a test subject for the same scorecard, and its boundaries must be checked against the current contract and plan. Treat a product's marketing page as a lead for questions, not as proof of deletion completion. Hosted search also creates lock-in when its query language, archive format, or field mapping cannot be reproduced elsewhere.
This approach is unsuitable when your team cannot operate a deletion queue or review data-processing terms. In that case, choose a service with contractual erasure evidence and a simpler export workflow, even if its query tooling is less flexible. Stick with a self-hosted pipeline when jurisdictional control and reproducible deletion matter more than low setup effort.
A rollout rule for the pricing flag
Before enabling the new rule for one support cohort, run a dry deletion and export against synthetic subjects. Confirm that the cost report can group bytes by tenant and flag variant, then confirm that the privacy receipt contains no transcript text. During rollout, alert on retention-job lag, export failures, and unexpected growth in distinct label values.
Keep less.
I once expected the largest savings to come from lowering the sample rate. The more durable change was removing a free-form label from every event; the label had no decision value and made aggregation expensive. We had added it to help a support queue, then discovered that queue already had a bounded ticket id, while the label multiplied distinct series for every locale, retry, and experiment branch. Removing it required changing the serializer, replaying a fixture, and checking the export schema, but it reduced the retention term without weakening the pricing decision. That is why the review asks “what will we stop keeping?” before it asks “which plan is cheapest?”
Keep a small, immutable policy record: purpose, legal basis, fields, retention period, deletion SLA, export schema, and owner. Revisit it when the flag becomes a permanent pricing rule. Observability should explain the system, but it should not quietly become the system's longest-lived customer database.
References
- https://gdpr-info.eu/art-5-gdpr/
- https://gdpr-info.eu/art-17-gdpr/
- https://gdpr-info.eu/art-20-gdpr/
- https://www.edpb.europa.eu/sme-data-protection-guide_en
- https://clickhouse.com/docs
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE
- https://www.rfc-editor.org/rfc/rfc8259
Top comments (0)