Fraud Detection Preprocessing

Introduction

Practice a focused Java Stream API coding question: Fraud Detection Preprocessing. Solve it first with a stream pipeline, then compare it with the imperative alternative.

Purpose of this lesson

Build interview-ready Stream API muscle memory. Difficulty: Hard - XP: 100 - Estimated time: 20 min - Tags: real-world, fraud, filter-sort-limit.

Understanding the topic

Problem statement: Extract high-risk transactions for fraud model preprocessing.

Sample input: transactions with amount, country, flagged merchant
Expected output: List of transactions over threshold or from flagged merchants

Approach: Filter using risk predicates, sort by amount descending, and limit records for review.

Syntax reference

Stream solution:

List<Transaction> reviewQueue = transactions.stream()
    .filter(tx -> tx.amount().compareTo(limit) > 0 || flaggedMerchants.contains(tx.merchantId()))
    .sorted(Comparator.comparing(Transaction::amount).reversed())
    .limit(100)
    .toList();

Alternative solution:

List<Transaction> reviewQueue = new ArrayList<>();
for (Transaction tx : transactions) {
    if (tx.amount().compareTo(limit) > 0 || flaggedMerchants.contains(tx.merchantId())) {
        reviewQueue.add(tx);
    }
}
reviewQueue.sort(Comparator.comparing(Transaction::amount).reversed());
if (reviewQueue.size() > 100) reviewQueue = reviewQueue.subList(0, 100);

Informative example

Dry run: Only risky transactions enter the queue; sorting prioritizes the largest amounts; limit caps analyst workload.

• Follow-up: Why can sorting all risky rows be expensive?
• Follow-up: Which parts should move to the database in production?

Complexity analysis

• Time: O(n log n)
• Space: O(n)

Real-world use

Interactive challenge: complete the starter code, then compare with the reference solution.

static Object solve(List<?> input) {
    // TODO: write the Stream pipeline
    return null;
}

Reference solution:

List<Transaction> reviewQueue = transactions.stream()
    .filter(tx -> tx.amount().compareTo(limit) > 0 || flaggedMerchants.contains(tx.merchantId()))
    .sorted(Comparator.comparing(Transaction::amount).reversed())
    .limit(100)
    .toList();

Hints:
- Start with the operation that changes the number of elements.
- Use a terminal operation that returns exactly the expected output type.
- Write an empty-list test before the happy path.

Best practices

• Name the terminal operation and explain why it ends the pipeline.
• Mention how nulls, empty inputs, duplicates, and ordering affect the answer.
• State when a loop is clearer than a Stream pipeline.

Common mistakes

• Calling get() on an empty Optional instead of handling absence.
• Using sorted() for a problem that only needs one pass.
• Mutating external state inside map, filter, or forEach.

Debugging tips

• Print the intermediate result after each pipeline stage when the output surprises you.
• Temporarily replace method references with lambdas so you can inspect parameter names and values.

Optimization strategies

• Avoid unnecessary distinct(), sorted(), and boxing on hot paths.
• Use primitive streams such as mapToInt when aggregating large numeric collections.

Advanced interview questions

Hands-on exercise

Practice progress metadata: difficulty=Hard, xp=100, estimatedTime=20 min, tags=real-world, fraud, filter-sort-limit.

Summary

You solved Fraud Detection Preprocessing with Streams, compared it against an imperative alternative, reviewed complexity, and captured interview follow-ups.

Purpose of this lesson

Practice Stream API interview questions with production-style trade-offs, not just syntax recall.

Step-by-step explanation

1. State the input, output, and edge cases before writing the pipeline.
2. Choose the smallest useful Stream operation: filter, map, flatMap, reduce, or collect.
3. Compare the Stream answer with the imperative alternative and explain readability trade-offs.
4. Check performance notes: stateful operations, boxing, sorting, distinct, and parallel overhead.

Interactive workflow diagram

Debugging tips

• Insert a temporary peek() only while debugging, then remove it before committing.
• If the result is missing rows, inspect every predicate in filter() with a small sample input.
• When collectors produce unexpected maps, print the classifier key for each element.
• When NOT to use Streams: complex branching, heavy mutation, tiny hot loops, or code where a clear loop is easier to review.

Optimization strategies

• Why distinct() can be expensive: it keeps a set of seen values and depends on correct equals/hashCode.
• When parallel streams hurt performance: small data, blocking I/O, shared mutable state, or expensive splitting.
• Common mistakes with reduce(): non-neutral identity values and non-associative accumulators break parallel correctness.
• Stream pipeline optimization: filter early, avoid intermediate collections, prefer primitive streams for numeric aggregation.

Enterprise example

Teams at Netflix, Uber and Goldman Sachs apply Fraud Detection Preprocessing daily — usually wrapped behind Spring Boot services with observability hooks (Micrometer + OpenTelemetry).

Interview questions & answers

Summary

Use this question to practice both coding and explanation: the strongest interview answers include edge cases, trade-offs, and when not to use Streams.