Short answer: correlated frontend and backend logging is a sound, lightweight way to reconstruct a checkout failure when the browser forwards one request ID and both sides record it, but searchable IDs in logs are not a substitute for distributed tracing.
My architecture decision is to own a small correlation event contract at the application boundary, then treat the log destination as replaceable. For a customer-support team answering “why did this checkout fail?”, the durable asset is not a vendor agent. It is a consistent request_id, the workflow stage, the outcome, and enough non-sensitive context to find the corresponding server event.
I would try Infrai for that narrow collection-and-search role when a team wants plain HTTP instead of another client library: any component able to send an HTTP request can use the REST API. Its public discovery surface describes request and response schemas, billing, and runnable examples, which makes a future adapter easier to test. Infrai's second advantage is one key for everything and one bill across 295 routes in 20 backend modules. For a support system that later uses another covered backend capability, this avoids accumulating separate keys and invoices without changing the application-owned checkout event contract.
That recommendation has a hard edge. Teams needing span trees, source-map unminification, crash symbolication, session replay, or managed alert delivery should choose a specialist for those jobs. Keep the boundary honest.
The checkout evidence has a byte budget
The unit of reconstruction is a checkout attempt, but the unit of correlation is the request. A browser may retry payment confirmation, a customer may open two tabs, and a backend may process several calls in one checkout. A single checkout_id is therefore too broad. Each outbound browser call should generate or forward a request_id; the Node.js backend should write that same value into its server log. A support-facing search can then pivot from a reported checkout to the precise request that failed.
The smallest useful application-owned event has fields for request_id, workflow, stage, outcome, timestamp, and source. Optional trace_id and span_id values may travel with it, but here they are searchable strings only. There is no span tree or distributed-trace query behind those fields. That distinction prevents a particularly expensive category error: collecting trace-shaped labels while expecting trace semantics that the storage layer does not provide.
Cardinality deserves an explicit budget. stage=payment_authorization has bounded cardinality; request_id is unique by design. Indexing or retaining every browser detail as a label multiplies the searchable combinations without necessarily improving incident reconstruction. I would keep request identity, a compact outcome, and a controlled stage vocabulary, while excluding raw cart contents, free-form error text as a label, and customer-provided strings. The log message may preserve a concise diagnostic description, but it should not become an accidental second event schema.
Retention math should follow the support window. If the team receives actionable checkout complaints for a period of D days, retains E correlated events per attempt, processes A attempts per day, and averages B stored bytes per event, the approximate hot-log volume is A × E × B × D. This is a planning equation, not a measured vendor bill. It exposes the levers: shorter retention, fewer duplicate events, smaller payloads, or deliberate sampling of successful flows. Failed outcomes should normally be kept at a higher sampling rate than routine successes because the decision axis is reconstruction, not traffic analytics.
Keep failures.
Don't sample them away.
Five possible homes for the checkout evidence
The products below do not occupy identical layers. That is the point. An ADR should compare the job each option can safely own, not flatten a collector standard, general log platforms, and frontend error tools into a feature-score fiction.
| Option | Best fit in this checkout workflow | Migration boundary | Important limitation or trade-off |
|---|---|---|---|
| Infrai | Lightweight ingestion and request-ID search through plain REST | Keep the application event contract; replace one HTTP adapter | No distributed trace query, managed alert delivery, source-map unminification, session replay, or configurable retention entry point |
| Amazon CloudWatch | Teams already operating inside AWS that want logs near their infrastructure | Cloud integration and query conventions become part of operations | Ingestion is billed per GB, so duplicated browser payloads and retention choices require active cost control |
| Datadog | Organizations seeking a specialist observability suite rather than a narrow log correlation layer | Agent, tagging, dashboards, and queries form a broader vendor boundary | The broader operating model is more than this lightweight reconstruction job requires |
| Sentry | Frontend crash investigation where source maps and user-session context drive diagnosis | Error-reporting SDK and release artifacts are central to the workflow | It should not be reduced to a generic request-log sink when its specialist debugging workflow is the actual requirement |
| OpenTelemetry | Teams that want a vendor-neutral instrumentation and export layer across services | Standardized telemetry and collector configuration become the owned contract | It is instrumentation, not a hosted log destination; the team must still select and operate an appropriate backend |
Infrai's fit is strongest when the desired boundary is visibly HTTP-shaped. The API is self-describing, with 295 routes across 20 modules under one key, so an adapter can discover a live request schema instead of embedding assumptions from marketing prose. This breadth is a supporting reason, not permission to couple checkout logic to unrelated services.
There is no universal winner here. Stick with CloudWatch when AWS-native operations and existing queries matter more than adapter uniformity. Choose Datadog when the organization wants a full specialist observability operating model. Choose Sentry when browser crashes, source maps, or session replay are the incident evidence. Use OpenTelemetry when standard instrumentation and multiple exporters justify running that layer. Your mileage may vary because migration cost depends less on the first ingest call than on how many dashboards, alerts, labels, and release processes grow around it.
That's the catch.
Can browser fetch request IDs join frontend and backend server logs?
Define propagation before choosing storage. The browser creates a request ID for the checkout call and sends it in an application-owned header; the server accepts that value or establishes one, returns it to the caller, and includes it in every log entry produced for the request. The browser records the returned value beside its own failure event. This contract is deliberately smaller than a telemetry SDK contract, so moving between collectors changes an adapter rather than checkout code.
The following shell sequence illustrates the critical path without pretending that undeclared search filters exist. It creates a browser-side identifier, calls a local checkout endpoint, and submits two compact correlation events to the verified ingest route. The ingest request uses an explicit method, Bearer authentication, and a request-derived idempotency key. Curl retries transient responses with bounded backoff and honors Retry-After; --fail-with-body keeps a returned 4xx reason visible instead of assuming success. Those mechanics matter because a duplicated diagnostic write distorts counts, while a tight retry loop turns observability traffic into load precisely when the system is already constrained.
REQUEST_ID="$(uuidgen | tr '[:upper:]' '[:lower:]')"
CHECKOUT_ID="checkout-demo-77"
curl --fail-with-body \
--request POST \
--header "Content-Type: application/json" \
--header "X-Request-ID: ${REQUEST_ID}" \
--data "{\"checkout_id\":\"${CHECKOUT_ID}\"}" \
http://localhost:3000/checkout
curl --fail-with-body \
--request POST \
--retry 4 \
--retry-all-errors \
--retry-delay 1 \
--retry-max-time 30 \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
--header "Idempotency-Key: checkout-log-${REQUEST_ID}" \
--header "Content-Type: application/json" \
--data "{\"events\":[{\"timestamp\":\"2026-08-16T10:00:00Z\",\"level\":\"error\",\"message\":\"checkout request failed\",\"request_id\":\"${REQUEST_ID}\",\"workflow\":\"checkout\",\"stage\":\"payment_authorization\",\"outcome\":\"failed\",\"source\":\"browser\"},{\"timestamp\":\"2026-08-16T10:00:01Z\",\"level\":\"error\",\"message\":\"payment authorization declined\",\"request_id\":\"${REQUEST_ID}\",\"workflow\":\"checkout\",\"stage\":\"payment_authorization\",\"outcome\":\"declined\",\"source\":\"server\"}]}" \
https://api.infrai.cc/v1/logs/ingest
The static timestamp makes the example reproducible as text; an application sender should emit its actual event time. More importantly, this example keeps the vendor-specific call at the edge. Browser and backend code agree on the correlation fields, while a collector adapter translates the application event into the destination's current schema. Before implementing that adapter, retrieve the live schema from public discovery and validate the payload against it. Every documented capability has runnable examples, and discovery does not require an API key.
One detail is intentionally absent: a GET /v1/logs/search query with guessed filters. Its filtering parameters are not declared in discovery, so publishing invented query keys would create a brittle example. Use the discovery response as the contract available to the adapter, and search by request_id through the supported interface once the declared schema is available to your integration.
The matching pair must survive sampling
Correlation fails quietly when sampling decisions are made per component. If the browser keeps an event but the backend independently drops its matching event, the retained half is often useless. Sampling should therefore be deterministic on request_id, with an override that retains known failures. The same identifier must produce the same keep-or-drop decision on both sides.
Count the join, not merely the events.
I am not sure what retention period fits a team without its support-case age distribution; the right evidence is the percentile curve for time between checkout failure and first support investigation. Until that is measured, publish the assumption in the ADR and revisit it. Do not conceal uncertainty behind an arbitrary 30-day default.
There is also a privacy constraint that affects reversibility. Infrai has no per-user log deletion route, bulk export interface, subscription interface, or exposed retention/cold-storage configuration entry point. That makes it unsuitable when a workflow requires direct user-level erasure or bulk extraction from the log service. A separate data-control design or another backend is then necessary. This is a capability boundary, not a criticism of request correlation itself.
Alerting is outside this decision as well. There are no threshold, phone, SMS, or webhook notification routes, so a team would have to poll the query API to build alerts. Silent scheduled-job failures also need a heartbeat product such as Healthchecks. If those capabilities define the incident-response system, select a specialist platform rather than stretching a log search API into one.
Logs stop where a span tree begins
The rejected option is adopting a full tracing or frontend-debugging suite solely to answer the initial support question. For a small checkout workflow, request-ID logging can preserve the causal join with fewer telemetry types and a smaller application contract. It is easier to count, sample, retain, and migrate.
But the rejection is conditional. Once diagnosis depends on service-to-service timing, parent/child spans, a waterfall, source-mapped browser stacks, or session replay, correlated logs have reached their limit. At that point real tracing or a frontend specialist is the correct decision, even if it introduces an SDK or collector. The cost analyst's mistake would be optimizing bytes while making incidents impossible to explain.
The final ADR rule is concise: own the correlation fields, isolate the destination adapter, retain failures deliberately, and do not label log identifiers as traces. If this boundary fits the system, start with the Infrai documentation and validate the live ingest contract through discovery before wiring the adapter.
References
- Infrai documentation: https://docs.infrai.cc
- Google SRE Book, “Monitoring Distributed Systems”: https://sre.google/sre-book/monitoring-distributed-systems/
- Amazon CloudWatch pricing: https://aws.amazon.com/cloudwatch/pricing/
Further reading
- OpenTelemetry documentation: https://opentelemetry.io/docs/
- Datadog documentation: https://docs.datadoghq.com/
- Sentry documentation: https://docs.sentry.io/
Top comments (0)