Sub-50ms Real-Time Fraud Detection: Go 1.24 Clean Architecture, GoRules Decision Graphs, and Hybrid Hot/Cold Storage

In payment processing, every millisecond added to the critical checkout path directly damages conversion rates. Yet failing to detect high-risk transactions—such as unauthorized cash-out schemes, account takeover velocity spikes, or fraudulent merchant registrations—leads to catastrophic chargeback ratios and regulatory fines.

The classic architectural dilemma in Fraud Detection Systems (FDS) is twofold:

1. Rule Agility vs Code Deployments: Risk and compliance teams need to adjust risk rules daily as fraud patterns evolve, without waiting for backend engineering sprints or service restarts.
2. Evaluation Latency vs Deep Behavioral History: Querying 30 days of historical merchant/customer transaction volume inside the live payment loop causes database connection exhaustion.

Here is the engineering design of a high-throughput Fraud Detection & Risk Management Middleware built with Go 1.24, GoRules.io, and a Smart Hybrid Hot/Cold Data Layer.

1. System Architecture & Evaluation Modes

The middleware is structured according to Hexagonal / Clean Architecture (Ports & Adapters) to ensure complete isolation of domain logic from external transport drivers and databases:

[ Core Payment Gateway / Upstream Microservices ]
                   │
                   ▼ (gRPC / High-Speed REST)
┌────────────────────────────────────────────────────────┐
│ fds-middleware (Go 1.24 Engine)                        │
│                                                        │
│  [ Inbound Handlers (Chi Router / gRPC Protobuf) ]    │
│                     │                                  │
│                     ▼                                  │
│  [ Evaluation Service (Context Coordinator) ]          │
│         │                          │                   │
│         ▼                          ▼                   │
│  [ GoRules Adapter ]      [ Aggregation Engine ]       │
│  (HTTP Client + Pool)     (Hourly Rolling Buckets)     │
│         │                          │                   │
│         ▼                          ▼                   │
│  External GoRules.io        Redis Hot-Tier             │
│  Decision Engine            (Atomic Pipelines & Lua)   │
│  (Zero-Downtime Graphs)            │                   │
│                                    ▼ (30s Async Flush) │
│                             PostgreSQL (Cold-Tier)     │
│                             (entity_summaries UPSERT)  │
│                                                        │
│  [ Transactional Outbox Worker ]                       │
│  Guaranteed At-Least-Once Delivery -> Kafka / Redpanda │
└────────────────────────────────────────────────────────┘
                   │
                   ▼ (JWT Auth + RBAC)
[ fds-fe Dashboard (React 18 + Tailwind + Chart.js) ]
  • Live Traffic Heatmaps & Decision Breakdown
  • Behavioral Trends & Forensic Raw JSON Replay

The engine serves two distinct, mission-critical workflows:

A. Merchant Onboarding Screening (MERCHANT_ONBOARD)

When a merchant registers on the payment gateway, the core system submits their corporate legal identity, stakeholder details, and bank settlement account. The engine verifies:

• Business entity legality (PT, CV, Individual).
• Completeness of KYC/KYB documentation (tax IDs, business licenses, bank statement verification).
• Settlement bank account reputation.
• Projected turnover consistency against Merchant Category Codes (MCC).

B. Real-Time Transaction Fraud Screening (TRANSACTION)

During live customer payments, the engine ingests transaction telemetry (amount, timestamp, merchant ID, customer ID, device fingerprint, and IP geolocation) and returns a normalized decision within sub-50ms:

• APPROVE: Transaction cleared for payment routing.
• REJECT: Strong fraud indicator (e.g. device blacklisted, extreme volume during odd hours 01:00–04:00, or known cash-out signature).
• CHALLENGE: Moderate risk threshold triggered; forces step-up authentication (3D-Secure OTP or biometric challenge).
• MANUAL_REVIEW: Ambiguous pattern flagged for operational fraud analyst investigation.

2. Zero-Downtime Rule Management via GoRules.io

Hardcoding fraud rules in code is a recipe for operational gridlock. If a coordinated syndicate attacks at 2:00 AM, risk analysts cannot wait for a developer to edit conditional statements, run CI pipelines, and deploy new binaries.

We decoupled decision logic entirely using GoRules.io (Decision Tables and Decision Graphs):

[ Incoming Transaction Payload ]
            │
            ▼
┌──────────────────────────────────────────────┐
│ GoRules Decision Graph                       │
│                                              │
│  [ Velocity Check ] ──> Hourly spike > 5x?   │
│            │                                 │
│  [ Device Integrity ] ──> Rooted / Emulator? │
│            │                                 │
│  [ Time-of-Day Window ] ──> 01:00 - 04:00?   │
│            │                                 │
│  [ Entity Collision ] ──> Merchant-Buyer match? │
│            │                                 │
│            ▼                                 │
│  [ Decision Matrix ]                         │
│  Compute Risk Score (0 - 100) & Flags        │
│  Map to APPROVE / REJECT / CHALLENGE         │
└──────────────────────────────────────────────┘

The Go engine maintains a tuned HTTP client with keep-alive connection pooling to GoRules. When risk teams publish a new rule graph in GoRules Studio, the engine adopts the logic immediately on the next incoming request without dropping a single packet.

3. Sub-50ms Latency via Non-Blocking Async Ingestion

A transaction evaluation request must complete almost instantly. If the engine performed synchronous database inserts for audit logs and behavioral history, database write locks would choke the gateway during traffic surges.

We achieved a consistent p99 latency under 45ms through non-blocking asynchronous dispatch:

func (s *EvaluationService) EvaluateTransaction(ctx context.Context, req *EvaluationRequest) (*EvaluationResponse, error) {
    startTime := time.Now()

    // 1. Synchronously fetch live decision from GoRules (< 25ms)
    decision, err := s.gorulesClient.Evaluate(ctx, req)
    if err != nil {
        return nil, err
    }

    latency := time.Since(startTime).Milliseconds()

    // 2. Fire-and-forget evaluation audit log to PostgreSQL via goroutine
    go func(payload *EvaluationRequest, res *EvaluationResponse, lat int64) {
        bgCtx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
        defer cancel()
        _ = s.repo.SaveEvaluationLog(bgCtx, payload, res, lat)
    }(req, decision, latency)

    // 3. Atomically update real-time velocity counters in Redis
    go func(payload *EvaluationRequest, score float64) {
        bgCtx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
        defer cancel()
        _ = s.aggregationService.RecordTransaction(bgCtx, payload, score)
    }(req, decision.RiskScore)

    // 4. Return decision immediately to upstream gateway
    return decision, nil
}

4. Smart Hybrid Hot/Cold Storage Architecture

To detect velocity anomalies (e.g., "Has this customer card attempted 5 payments across 3 different merchants in the last 15 minutes?"), the system requires immediate historical awareness.

Instead of running heavy COUNT() and SUM() aggregate queries on relational tables, we split storage into Hot (Memory) and Cold (Disk) tiers:

HOT TIER (Redis)                               COLD TIER (PostgreSQL)
──────────────────────────────────────────────────────────────────────────────────────────
• Atomic Lua Scripts & Pipelines               • Durable entity_summaries table
• Hourly rolling buckets (TTL: 2 hours)        • 30-second periodic background flusher
• Tracks: tx_count, total_amount, max_score    • Efficient UPSERT: ON CONFLICT DO UPDATE
• Zero database read load on live traffic      • Long-term historical trend queries (7-30d)

Warmup Mechanism on Startup

When a backend container starts up or restarts, the Warmup module queries the previous 2 hours of summarized data from PostgreSQL and hydrates the Redis key space. This completely eliminates the "cold-cache penalty" where initial evaluations could misjudge transaction velocity.

5. Reliable Audit Delivery via Transactional Outbox

When a transaction is flagged as high-risk or confirmed fraudulent, secondary compliance services, merchant notification systems, and SIEM monitoring tools must be notified.

To avoid dual-write inconsistencies between the local database and message brokers, the engine implements the Transactional Outbox Pattern:

• The evaluation record and an outbound event are committed inside the exact same local ACID transaction in PostgreSQL (outboxes table).
• An isolated background worker using Go concurrency semaphores reads pending outbox events and pushes them to Kafka / Redpanda with guaranteed at-least-once delivery.
• If the message broker is temporarily unreachable, the outbox worker backs off and retries deterministically without losing audit records.

6. Key Performance Metrics

METRIC                              PERFORMANCE BENCHMARK
───────────────────────────────────────────────────────────────────────────
Evaluation Latency (p50)            18 ms
Evaluation Latency (p99)            42 ms
Rule Propagation Time               0 ms (Zero deployment/compile time)
Concurrent Evaluation Throughput    5,000+ requests/sec per replica
Cache Cold-Start Recovery           < 3 seconds (Automated DB Hydration)
Audit Delivery Reliability          100% At-Least-Once (Transactional Outbox)

By decoupling business rule administration from backend binaries and leveraging Go 1.24's concurrency primitives alongside a hybrid memory-disk storage hierarchy, the system delivers bank-grade fraud mitigation without sacrificing payment processing speed.