Short answer: For searchable logs from a nightly marketplace pipeline, emit one compact structured event per state transition, carry stable request, user, item, and run identifiers into backend ingest, and retain verbose payload detail outside the expensive searchable tier.
Start with the event count and retained bytes. The logger library is a secondary choice. Suppose a nightly run processes 10,000,000 listings and emits four 1,200-byte events per listing. That is 48,000,000,000 bytes before transport framing, replicas, indexes, or compression; keep 30 nights searchable and the raw-event baseline becomes 1,440,000,000,000 bytes. These are hypothetical inputs, not a benchmark. Replace them with counts and byte measurements from the pipeline.
Small fields become large bills.
What is the logging bill actually made of?
A logging bill is rarely explained by the application logger alone. Model at least four terms: bytes accepted by the ingest boundary, bytes expanded into searchable indexes, bytes retained in the searchable tier, and query work. I don't know which term dominates in your account until those four quantities are separated. For this nightly workload, cost attribution also needs a fifth dimension: the pipeline run that caused the spend. A daily total without run_id can tell finance that logging grew; it cannot tell the storage team whether retries, a new validation stage, or larger event bodies caused the growth.
Use a byte budget before choosing retention. In the hypothetical run above, reducing four events to two changes the baseline from 48 GB to 24 GB per night. Reducing an event from 1,200 bytes to 700 bytes changes it from 48 GB to 28 GB per night. Doing both changes it to 14 GB. This arithmetic deliberately ignores backend-specific compression and indexing multipliers because they vary; measure encoded bytes immediately before ingest, then reconcile that figure with the backend's accepted and stored-byte counters.
The unit of attribution should be a pipeline run and a producing component, not a person. user_id is still useful for tracing a marketplace action back to the pipeline input, but it should be a stable internal identifier rather than an email address or display name. Put run_id, stage, event_name, and service beside it. Then aggregate encoded_bytes and event_count by those dimensions. A team can identify a noisy stage without indexing an arbitrary message string or exposing human-readable account data.
This is where a harmless-looking logging choice turns into storage architecture. A serialized exception copied into every retry, a full listing document repeated at three stages, or unbounded field names derived from marketplace categories all multiply the retained searchable surface. The failure mode isn't merely a larger invoice — broad fields make ownership ambiguous, while repeated payloads increase the sensitive material that retention and deletion policies must govern.
How should structured JSON logs carry request and user IDs into backend ingest?
Treat the event as a versioned contract. Every record needs a timestamp, severity, event name, schema version, service, environment, and pipeline run identifier. Add request_id when work originates from an API request, user_id when an authenticated marketplace actor is relevant, and a separate item_id for the listing. Never overload one identifier to mean another. A nightly retry may have no live request, so request_id should be absent rather than filled with a synthetic value that looks real.
The Node.js application logging API should accept structured fields, not a preformatted sentence. Whether the team selects Pino or Winston, the acceptance test is the same: bindings added at the request boundary must survive asynchronous work, the emitted record must be valid JSON, and backend ingest must preserve field types. Keep the human message short and stable. Search event_name = listing_validation_failed plus run_id, then inspect typed fields such as rule_id; don't turn prose into a schema.
Here is the event contract expressed as Python data so the example remains executable and the serialized output remains valid JSON:
import json
event = {
"timestamp": "2026-08-21T02:14:07.381Z",
"severity": "warn",
"schema_version": 3,
"service": "catalog-pipeline",
"environment": "production",
"event_name": "listing_validation_failed",
"run_id": "run_20260821_01",
"request_id": "req_7f2c91",
"user_id": "usr_18420",
"item_id": "lst_903118",
"stage": "normalize",
"rule_id": "currency_code",
"attempt": 2,
"encoded_bytes": 412,
"message": "Listing validation failed",
}
print(json.dumps(event, separators=(",", ":"), sort_keys=True))
The values are illustrative. The boundaries matter: identity, execution, failure classification, and cost attribution remain independently searchable. If privacy policy forbids storing a user identifier in the logging system, omit it and keep the authorized join in a separate audit system. Correlation convenience does not override data minimization.
Propagation deserves a test because it can fail quietly. Generate one request ID at the trusted ingress, reject or replace malformed external values according to policy, attach it to the execution context, and verify that every event created by one asynchronous job carries the same value. A pipeline that fans out must retain the parent run_id while assigning child job identifiers. Otherwise one high-volume retry can appear to be thousands of unrelated failures.
Measure cardinality before it reaches searchable storage
Storage volume is only half the risk. Fields intended for grouping should have controlled value sets: severity, stage, event_name, and rule_id are good candidates. Identifiers such as request_id, user_id, and item_id have high cardinality by design. They are valuable for exact lookup, but grouping dashboards or metric labels by them creates a different cost and operational profile. Prometheus naming guidance says a metric should represent the same logical thing across label dimensions and warns that every unique label combination creates a new time series. Logs and metrics aren't interchangeable, yet the cardinality warning transfers cleanly: decide which fields support aggregation and which support exact retrieval.
Run a pre-deployment sample through a local analyzer. This script reads newline-delimited JSON, calculates encoded size, and reports distinct values without depending on a commercial backend:
import json
import sys
from collections import Counter, defaultdict
GROUP_FIELDS = ("service", "stage", "event_name", "severity")
counts = Counter()
distinct = defaultdict(set)
total_bytes = 0
events = 0
for raw_line in sys.stdin.buffer:
line = raw_line.strip()
if not line:
continue
event = json.loads(line)
events += 1
total_bytes += len(line) + 1
counts[tuple(event.get(field) for field in GROUP_FIELDS)] += 1
for field in (*GROUP_FIELDS, "request_id", "user_id", "item_id"):
if field in event:
distinct[field].add(str(event[field]))
report = {
"events": events,
"encoded_bytes": total_bytes,
"average_event_bytes": round(total_bytes / events, 1) if events else 0,
"distinct_values": {field: len(values) for field, values in distinct.items()},
"largest_groups": [
{"group": dict(zip(GROUP_FIELDS, key)), "events": count}
for key, count in counts.most_common(10)
],
}
print(json.dumps(report, indent=2, sort_keys=True))
Feed it representative success, validation-failure, retry, and terminal-failure samples. Don't extrapolate from error-only fixtures: a tiny success event repeated millions of times can outweigh a large exception record. Also test malformed JSON, missing required fields, an integer accidentally emitted as a string, and a new schema version arriving before the saved search is updated. These are contract failures, and each can make retained data impossible to query consistently even though ingest accepted it.
Keep the original sample and analyzer output with the deployment artifact. This makes an event-size increase reviewable. It also gives the owning team evidence when a billed quantity differs from application-side bytes because of indexing, replication, or compression.
Retention tiers should follow questions, not severity labels
Severity is an unreliable retention policy by itself. A successful state transition may be the only evidence that a listing reached a stage, while thousands of identical warnings may add no diagnostic value after their count and first examples are preserved. Define retention around questions: what must be searchable during the on-call window, what must remain available for delayed marketplace disputes, and what only supports aggregate capacity planning?
| Data class | Searchable form | Retention decision | What is lost when reduced |
|---|---|---|---|
| State transitions | Compact typed event | Keep through the operational investigation window | Exact stage history after expiry |
| Repeated validation failures | Count by rule plus bounded examples | Sample details; retain aggregate counts longer | Every affected item cannot be inspected from logs alone |
| Exception details | Deduplicated event with stable fingerprint inputs | Keep representative detail and counts | Rare parameter-specific variants may disappear |
| Original listing payload | Governed source or audit store, not duplicated into logs | Follow the source system's policy | One-click reconstruction from the log backend |
| Cost measurements | Bytes and events by run, service, and stage | Keep long enough to compare pipeline changes | Fine-grained historical attribution after expiry |
Event grouping needs the same skepticism. Sentry documents that grouping uses event fingerprints and that custom fingerprints can alter grouping. The general lesson is to define stable failure identity from controlled fields such as exception type, stage, and rule, then test it against fixtures. If a fingerprint includes a request ID, every occurrence becomes unique; if it ignores the rule that failed, unrelated defects collapse into one group. I'm not sure where the right boundary sits for your validation taxonomy because that depends on which rules share remediation. A labeled fixture set resolves the uncertainty better than intuition.
The catch is deliberate information loss. Sampling repeated failures and expiring item-level events make the searchable tier smaller, but an investigation outside the retention window may recover only aggregate counts and a few examples. This design is not suitable when regulation, contractual disputes, or fraud investigations require an immutable event for every transition. In that case, keep the complete governed record in an audit-oriented store and expose only fields needed for operational search; don't ask an application log index to serve simultaneously as debug workspace, legal record, and source of truth.
The deployment gate is a query, a budget, and a deletion test
Before rollout, replay a representative fixture set and require three outcomes. First, one query using run_id and event_name must reconstruct a failed item's stage sequence without parsing message. Second, the sample's measured average size and event count must fit the agreed per-run byte budget. Third, deletion or expiry must remove the user-correlated search surface according to policy without destroying the separately governed system of record.
Then canary the schema. Compare event counts by stage against pipeline counters, watch missing-field rates, and split reports by schema_version until every saved query understands the new contract. A rollback must restore both emission and query compatibility; changing a field name back in application code does not repair already-ingested events. Keep readers tolerant of the previous version during the migration window.
The stop rule matters most: do not retain full listing documents, duplicate stack traces for every retry, or arbitrary context maps in the searchable tier. You give up late, item-specific reconstruction from logs and may need the governed source record to investigate an old case. That is a real cost. It is also an explicit, reviewable trade rather than accidental retention driven by whatever the logger happened to serialize.
Further reading
The sources below support the cardinality and failure-grouping criteria used in this design.
Top comments (0)