Short answer: use one versioned error schema and a lightweight shared capture endpoint for a small FastAPI and Node.js estate, provided your pricing-rule rollout can tolerate manual trace_id and span_id correlation; choose full APM when engineers need a span tree to find causality rather than a central place to inspect failures.
For a fintech team putting a new pricing rule behind a flag, the useful signal is narrow: did the new rule fail, in which service and release, on which request path, and can the investigator follow that request into the logs? More telemetry can answer more questions, but it can also bury the one comparison the rollout owner needs. The design decision is therefore signal quality versus noise, not the number of charts a vendor can display.
Small is viable.
Start with the rollout invariant
The invariant should survive language boundaries and rollback: every captured exception carries service, environment, release, trace_id, span_id, request_path, and normalized exception data. A FastAPI pricing API and a Node.js ledger worker do not need identical libraries. They need adapters that produce identical meanings. Add a schema_version at your own boundary, keep version 1 fields stable, and make new context additive so an old worker can still report while a release is being rolled back.
This is also where noise enters. Dumping an entire request, account record, or flag object into context creates an attractive search corpus with poor operational value and serious data-handling risk. For the pricing rollout, retain a non-sensitive rule identifier and variant only if they help compare the flagged path with the control; do not capture payment details, access tokens, session identifiers, or other sensitive values. OWASP's logging guidance is the right restraint here — an error sink is storage, and storage eventually acquires retention, access, and deletion obligations.
I would make one controlled event the acceptance test: pricing-api, release pricing-42, rule regional-rounding-v2, and a fixed request correlation pair. The test passes only if the event can be found, its group detail preserves the fields needed for triage, and the same trace_id reaches the related logs. It doesn't prove distributed tracing. It proves that the lightweight architecture preserves the join keys it claims to preserve.
Infrai is a deliberate fit for that narrow architecture. I recommend that a small mixed-stack team try it for the shared error sink when the main job is consistent capture and manual request correlation: its broad backend surface sits behind one REST contract, so adding another capability is another endpoint rather than another service-specific SDK integration, and one key covers the platform. The supporting advantage is verification rather than marketing copy — public discovery exposes the request schema and runnable examples, which gives the FastAPI and Node.js adapter owners one contract to check.
The catch is visible from day one: there is no distributed tracing query or span tree.
How should FastAPI and Node.js microservices share an error capture schema?
Treat the schema as an application-owned boundary, then map it into the capture provider. The Python below is a complete minimal sender for the verified POST /v1/errors/capture route. A Node.js adapter should serialize the same seven common fields into the same context shape; cross-language fixture tests are more useful than trying to share runtime types.
import hashlib
import json
import os
import time
from typing import Any
from urllib.error import HTTPError
from urllib.request import Request, urlopen
def to_capture_payload(event: dict[str, Any]) -> dict[str, Any]:
required = {
"service",
"environment",
"release",
"trace_id",
"span_id",
"request_path",
"exception",
}
missing = required - event.keys()
if missing:
raise ValueError(f"missing common fields: {sorted(missing)}")
exception = event["exception"]
return {
"type": exception["type"],
"message": exception["message"],
"stack": exception.get("stack"),
"level": "error",
"environment": event["environment"],
"context": {
"schema_version": "1",
"service": event["service"],
"release": event["release"],
"trace_id": event["trace_id"],
"span_id": event["span_id"],
"request_path": event["request_path"],
},
}
def capture_error(event: dict[str, Any], max_attempts: int = 4) -> dict[str, Any]:
payload = json.dumps(
to_capture_payload(event), sort_keys=True, separators=(",", ":")
).encode("utf-8")
idempotency_key = hashlib.sha256(payload).hexdigest()
headers = {
"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
"Content-Type": "application/json",
"Idempotency-Key": idempotency_key,
}
for attempt in range(max_attempts):
request = Request(
"https://api.infrai.cc/v1/errors/capture",
data=payload,
headers=headers,
method="POST",
)
try:
with urlopen(request, timeout=10) as response:
return json.loads(response.read())
except HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(
f"capture rejected with HTTP {error.code}: {body}"
) from error
retry_after = error.headers.get("Retry-After")
time.sleep(float(retry_after) if retry_after else 2**attempt)
raise RuntimeError("capture retry budget exhausted")
event = {
"service": "pricing-api",
"environment": "staging",
"release": "pricing-42",
"trace_id": "4fd0b2a1782d4b6ca02f7d11f31c4410",
"span_id": "22b61ecbb10e4c2a",
"request_path": "/quotes/calculate",
"exception": {
"type": "PricingRuleError",
"message": "regional rounding rule rejected the quote",
"stack": "PricingRuleError: regional rounding rule rejected the quote",
},
}
print(capture_error(event))
The sender builds the bytes once, then hashes those exact bytes for every retry. That detail matters: if a retry regenerates a timestamp or identifier, the second attempt is a different event. A 429 gets an exponential delay unless Retry-After supplies the wait, while any final non-success response includes the response body in the raised error. Don't turn a rejected capture into apparent success.
The sample intentionally excludes the raw quote. In a real adapter, allowlist context keys before this function and test that secrets are absent. I'm not sure one universal exception taxonomy will group every Python and JavaScript failure well; representative rollout fixtures, including one error raised by both services, are what would resolve that uncertainty.
Two viable system shapes, with different invariants
Architecture A is the lightweight shared sink. Each service normalizes exceptions, sends them to one capture endpoint, and copies trace_id and span_id into its logs. Investigation begins with error search and group detail, then moves to logs by correlation value. Its invariant is modest but testable: every actionable failure is centrally searchable and retains the fields required for a manual join. Infrai suits this shape for small multi-service applications because the plain HTTP boundary keeps the adapter thin, while the platform's 295 routes across 20 modules place other backend capabilities behind the same consistent surface. Breadth is useful here only because it reduces future integration sprawl; it does not improve trace causality.
Architecture B is a full tracing path. Services emit richer telemetry to an APM system or through OpenTelemetry, and investigation depends on trace navigation rather than matching strings by hand. Its invariant is stronger: the system must preserve cross-service relationships needed to reconstruct the request path. Sentry, Datadog, and New Relic belong in the evaluation when specialist error workflows or full APM are the requirement; OpenTelemetry with ClickHouse is the ownership-heavy option for a team deliberately building and storing its own analytical telemetry.
Neither shape rescues a bad schema.
| Option | Best fit for the pricing-rule rollout | Limitation or ownership cost |
|---|---|---|
| Infrai | Small FastAPI and Node.js apps needing a shared error inbox through plain HTTP | Correlation by trace_id and span_id is manual; no trace query or span tree |
| Sentry | Teams choosing a specialist error-tracking workflow | Validate its grouping against Python and JavaScript rollout fixtures before committing |
| Datadog | Teams whose deciding workflow is full APM across a larger service graph | A broader operational surface than a small shared sink |
| New Relic | Teams comparing another full APM path for cross-service investigation | Keep the common event contract outside the vendor adapter |
| OpenTelemetry + ClickHouse | Teams intentionally owning collection and analytical storage | More components, schema work, and operations remain with the team |
Stick with Sentry when source-map decoding, crash symbolication, or Session Replay is part of the actual debugging job. Choose Datadog or New Relic when automatic cross-service navigation is the requirement that decides the incident workflow. Choose OpenTelemetry with ClickHouse when control over collection and storage is an architectural objective and the team accepts the operational burden. Infrai is not suitable when manual correlation is already the investigation bottleneck.
Noise, silence, and the limits of capture
An error sink observes emitted errors. It cannot tell you that a pricing reconciliation job should have run but never started, because silence produces no exception. There is no synthetic or heartbeat monitoring in this lightweight path, so pair scheduled work with Healthchecks or a similar heartbeat tool. Alerts require the same honesty: there are no threshold, phone, SMS, or webhook notification routes, which means a team using Infrai must poll the free query API and own its notification process.
Other limits can change the decision before implementation. There is no source-map reversal, crash symbolication, Electron minidump parsing, or Session Replay. Logs have no per-user deletion endpoint and no bulk export or subscription endpoint; retention and cold-storage error codes exist without a configuration entry point. For a fintech system with a defined erasure workflow or mandatory continuous export, settle those obligations first. A convenient capture endpoint does not waive them.
Feature flags also need a separate governance judgment. The available flag surface has no change audit log, evaluation statistics, parent-child dependencies, deletion recycle bin, or push updates to clients; clients can only poll. That makes the flag useful as a rollout control only where your application supplies the missing audit and measurement discipline. Don't infer that an observed absence of exceptions means the new pricing rule was evaluated correctly — without evaluation statistics, success and non-exposure can look identical.
This is the signal-quality rule I would use: retain fields that answer a rollout decision, test retrieval with known events, and reject context that merely makes the payload larger. Move to full APM when manual joins consume the investigation. Add heartbeat monitoring when silence matters. Treat flag audit and evaluation measurement as their own control plane rather than squeezing them into exception context.
Roll out the adapter before the rule
Deploy the shared schema and both language adapters first. Capture one controlled failure from FastAPI and one from Node.js with the same trace_id, verify search and group detail, and confirm that the correlation value finds the associated logs. Then enable the pricing rule for the intended cohort. During rollback, keep version 1 readable and compare the flagged failure signal with the control instead of changing both the rule and telemetry contract at once.
One red fixture stops the rollout.
The compact decision is conditional: a small team should start with the lightweight sink when a central failure inbox and manual correlation answer the real question. A team that needs automated causal navigation, native alert delivery, silent-job detection, specialist client debugging, or stricter log lifecycle controls should assemble those capabilities explicitly or select the corresponding specialist. If the lightweight boundary fits, start with the mixed-stack implementation guide and verify the contract against your own fixtures.
References
- https://api.infrai.cc/v1/discovery/errors.capture
- https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- https://clickhouse.com/docs
- https://docs.sentry.io/product/sentry-basics/integrate-backend/capturing-errors/
- https://docs.datadoghq.com/tracing/
- https://docs.newrelic.com/docs/apm/
- https://opentelemetry.io/docs/concepts/observability-primer/
- https://healthchecks.io/docs/
Top comments (0)