GetHired.devBackend systems, explained from the build
Menu

SentinelFi

A fraud-detection microservices project used to explore how a system can make a fast product decision while preserving the evidence, uncertainty, and review history behind it.

The engineering problem

A fraud system can miss harmful activity or block a legitimate user. A useful design therefore needs more than a score: stable event contracts, bounded synchronous checks, asynchronous enrichment, replay-safe consumers, versioned policies, authorization, and an operator path for held decisions.

System map

A replay-safe fraud decision path

Each stage preserves the event identity and the reason behind a decision. That makes duplicate delivery survivable and gives an operator evidence to review.

  1. 01Transactional outboxRecord the pending action and event together.
  2. 02Event enrichmentAttach named, versioned risk signals without losing provenance.
  3. 03Decision policyMap evidence to allow, challenge, review, or deny.
  4. 04Operator reviewRetain overrides, reasons, and replay history.

Design evidence, not invented scale

SentinelFi does not yet have a publishable production benchmark. These figures describe the implemented decision model and its review boundary, not fraud-detection accuracy.

1
Stable event IDCarried across retries and consumers.
4
Decision statesAllow, challenge, review, and deny.
6
Documented stagesFrom transaction to operator decision.
0
Repeated side effectsThe required replay invariant.

The pipeline slice

  1. The API records a pending action and an outbox event in one transaction.
  2. A relay publishes a versioned event with a stable event ID.
  3. Consumers enrich the event and record named risk signals.
  4. A versioned policy maps signals and score to allow, challenge, review, or deny.
  5. An operator can review a held action and record an override reason.
  6. Replaying the original event must not repeat a completed side effect.

Evidence in the guide

Designing a fraud detection event pipeline in Node.js includes an event contract, transactional outbox, processed-event constraint, versioned signals, decision bands, audit record, missing-data states, monitoring plan, and uncomfortable-path test list.

What remains project work

Example rule weights and decision bands are illustrative and must not be treated as real fraud policy. A credible next step is to implement the complete slice, publish duplicate-delivery and failure-path tests, and document measurements from a named local test environment. The site will not claim fraud-detection accuracy or production scale without that evidence.

Code and author

See Aarav Chandel's GitHub profile for currently public repositories and project work.