Debug slow app with no errors?

• Hidden latency – log.info proves a step happened but hides the GAPS: time in the thread pool queue, waiting for a DB connection, silent retries, DNS resolution, TLS handshake, and GC pauses.
• Timeline segmentation – break the total request time into measurable segments: queue wait, connection acquisition, DB query, downstream HTTP call, serialization. Each segment is measured separately.
• Distributed tracing – tools like Jaeger and Zipkin show a span waterfall where each segment's actual duration is visible, including gaps and hidden retries within a single span.
• Common culprits – queue wait (thread pool saturated, tasks wait before execution), connection wait (HikariCP exhausted), silent retries (Spring Retry retries 3 times invisibly), DNS/TLS (first request to new host), GC pause (stop-the-world collection).

How do you debug a slow app with no errors?

The first step is to stop asking "why is it slow?" and instead ask "where is time accumulating?" Instrument each segment of the request and measure it separately.

package com.bank.diagnostics;

public class InstrumentedServiceDemo {
    public String getBalance(String accountId) {
        long totalStart = System.nanoTime();

        // Segment 1: queue wait (time between submission and execution start)
        long queueWait = System.currentTimeMillis() - taskSubmitTime;

        // Segment 2: DB connection acquisition
        long connStart = System.nanoTime();
        // Connection conn = dataSource.getConnection();
        long connWait = (System.nanoTime() - connStart) / 1_000_000;

        // Segment 3: DB query
        long queryStart = System.nanoTime();
        // ResultSet rs = stmt.executeQuery(sql);
        long queryTime = (System.nanoTime() - queryStart) / 1_000_000;

        // Segment 4: downstream HTTP (may include hidden retries)
        long httpStart = System.nanoTime();
        // String response = httpClient.send(request);
        long httpTime = (System.nanoTime() - httpStart) / 1_000_000;

        long total = (System.nanoTime() - totalStart) / 1_000_000;
        System.out.printf("Total: %dms (queue: %dms, conn: %dms, "
                + "query: %dms, http: %dms)%n",
                total, queueWait, connWait, queryTime, httpTime);
        return "balance";
    }

    private long taskSubmitTime = System.currentTimeMillis();
}

What does distributed tracing show?

A span waterfall from Jaeger or Zipkin visualizes every segment's duration, including gaps between segments and hidden operations within a single span.

[───── Request: 2500ms ──────────────────────────────────────────]
  [── Queue wait: 800ms ──]
                           [── Conn wait: 500ms ──]
                                                   [─ DB: 200ms ─]
                                                                  [──── HTTP: 900ms ────]
                                                                  [retry1:300][retry2:300][ok:300]

The biggest contributor is queue wait (800ms), not the DB query (200ms). Without segmentation, you would optimize the DB query and gain only 200ms.

What are the hidden latency sources?

Six common sources of hidden latency that do not appear in application logs:

1. Queue wait: task submitted to thread pool, waits in queue before a worker picks it up.
2. Connection wait: getConnection() blocks while all connections are in use.
3. Silent retries: Spring Retry or Resilience4j retry 3x transparently. 3 x 300ms = 900ms.
4. DNS/TLS: first request to a new host triggers DNS lookup + TLS handshake.
5. GC pause: stop-the-world GC freezes all threads for 200ms+.
6. Thread scheduling: OS does not schedule the thread immediately after it becomes runnable.

What are common interview follow-up questions?

• How do you add tracing to an existing application? Use OpenTelemetry auto-instrumentation, which adds spans to HTTP calls, DB queries, and messaging without code changes.
• Is logging enough? No. Logs show events but not the gaps between them. Tracing shows the full request timeline.

What are common mistakes?

A common mistake is not understanding the concept fully before using it in production banking applications.

Wrong approach:

package com.bank.service;

public class TransferService {
    public void transfer(String fromAccount, String toAccount, double amount) {
        // WRONG: using double for money
        double balance = getBalance(fromAccount);
        balance = balance - amount;
    }
    private double getBalance(String id) { return 10000.0; }
}

Correct approach:

package com.bank.service;

import java.math.BigDecimal;

public class TransferService {
    public void transfer(String fromAccount, String toAccount, BigDecimal amount) {
        // CORRECT: using BigDecimal for money
        BigDecimal balance = getBalance(fromAccount);
        balance = balance.subtract(amount);
    }
    private BigDecimal getBalance(String id) { return new BigDecimal("10000.00"); }
}

Always use BigDecimal for monetary calculations in banking systems to avoid floating-point precision errors.

What should a senior engineer know?

A senior engineer working on banking systems should understand the production implications of this concept.

• Performance impact. Measure with JMH before making assumptions about which approach is faster.
• Thread safety. In a multi-threaded banking service processing concurrent transactions, always consider whether the approach is thread-safe.
• Memory footprint. Use JFR and VisualVM to measure actual memory usage under realistic banking workloads.
• Monitoring. Set up JMX metrics and alerts for production banking applications.

package com.bank.monitoring;

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;

public class MemoryMonitor {
    public static void printMemoryUsage() {
        MemoryMXBean mem = ManagementFactory.getMemoryMXBean();
        System.out.println("Heap: " + mem.getHeapMemoryUsage());
        System.out.println("Non-Heap: " + mem.getNonHeapMemoryUsage());
    }
}

What are the edge cases?

Edge cases can cause unexpected behavior in banking applications. Here are some to watch for.

package com.bank.edge;

public class EdgeCaseDemo {
    public static void main(String[] args) {
        // Edge case 1: null handling
        String accountId = null;
        try {
            System.out.println(accountId.length());
        } catch (NullPointerException e) {
            System.out.println("Null account ID");
        }

        // Edge case 2: empty vs null
        String emptyId = "";
        System.out.println(emptyId.isEmpty());  // true
        System.out.println(emptyId == null);     // false

        // Edge case 3: boundary values
        java.math.BigDecimal zero = java.math.BigDecimal.ZERO;
        java.math.BigDecimal negativeBalance = new java.math.BigDecimal("-0.01");
        System.out.println(zero.compareTo(negativeBalance) > 0);  // true
    }
}

Null account ID
true
false
true

Always test with null values, empty strings, boundary values, and negative amounts in banking applications.