Java Programming Questions

Approach & idempotency key scheme

• Clients send Idempotency-Key (UUID v4) with POST. Server treats key scoped by client-id or API-key to avoid cross-client collisions.

Schema

• orders (id, customer_id, total, status, created_at...)
• idempotency_keys (key text PK, client_id, request_hash, status enum, response_body jsonb, created_at, last_used_at)

Transaction boundaries & flow

1. Begin DB tx.
2. INSERT INTO idempotency_keys (key, client_id, status='inflight') ON CONFLICT DO NOTHING RETURNING status.
   • If insert succeeds => proceed to create order, commit both order and UPDATE idempotency_keys SET status='completed', response_body=... in same tx or subsequent short tx using idempotency_keys row lock.
   • If row exists with status='completed' => return stored response (no-op).
   • If status='inflight' => wait/poll with timeout or return 409 with Retry-After.
     Use SELECT ... FOR UPDATE on idempotency_keys to serialize concurrent attempts for same key.

Garbage collection

• Retain completed records for TTL (e.g., 7–30 days) then delete via background job or partitioned table by date for fast drop.

Notes

• Store deterministic response (location, order id) so retries are safe. Use short locks to avoid contention and idempotency table partitioning for scale.

Zero-downtime plan

1. Add nullable column with default NULL (fast metadata change).
2. Deploy app version that writes new column for new writes and reads fallback to computed value if NULL.
3. Backfill gradually with chunked updates: update WHERE new_col IS NULL ORDER BY pk LIMIT 10000 in small transactions, with sleep between chunks; run multiple workers coordinated to avoid hotspots.
4. Use online tools (pt-online-schema-change or native DB features) if DB supports fast backfill.
5. Once backfill reaches safe threshold, set column NOT NULL using CHECK constraint then ALTER to set NOT NULL (post-verify), or add computed persisted column if DB supports it.

Avoid big transactions

• Use idempotent chunk updates with small tx size; avoid full table rewrite.

App compatibility

• Use feature flag and versioned reads; app reads computed default when NULL until migration finalized.

Validation

• Compare sample rows before/after, spot-check counts of NULLs, run invariant queries, monitor replication lag, and ensure no long locks. Have rollback by stopping backfill and reverting app writes if issues arise.

GET /users with pagination and X-Total-Count (Spring Boot)

Controller signature:

@GetMapping("/users")
public ResponseEntity<List<UserDto>> list(
  @RequestParam(defaultValue = "0") int page,
  @RequestParam(defaultValue = "20") int size) {
  Page<User> p = userService.findAll(PageRequest.of(page, size));
  HttpHeaders h = new HttpHeaders();
  h.add("X-Total-Count", Long.toString(p.getTotalElements()));
  return new ResponseEntity<>(p.getContent().stream().map(...).collect(toList()), h, OK);
}

Service: use Spring Data Pageable (userRepository.findAll(Pageable)) or manual SQL with LIMIT/OFFSET and a separate COUNT(*) query. Repository: Spring Data JPA returning Page<User>.

Testing: unit-test controller mapping and header presence using MockMvc; integration test with Testcontainers asserting pagination, boundary pages (page beyond last returns empty list and total count), invalid params (negative values) return 400, and correctness of X-Total-Count matching DB count.

Key components

• Pool manager maintaining idle and in-use sets.
• Acquisition algorithm: try take from idle queue; if empty and pool < max, open new connection; else wait with timeout and backpressure.
• Max pool size and wait policy: configurable max, exponential backoff or immediate failure (SQLTransientConnectionException) after timeout.

Validation & eviction

• Health-check on borrow (light validation query) or async validation for idle.
• Eviction thread scans idle connections, closes stale/broken ones after configured idleTimeout.

Leak detection

• Track borrow stack trace and timestamp; if held beyond leakThreshold, log warning and optionally close. Implement weak-reference based leak cleanup: schedule forced reclaim after grace period.

Thundering herd avoidance

• Use fairness queue with limited waiters; on exhaustion, requesters wait on Condition and wake a bounded number at a time. Use exponential backoff and circuit-breaker to reject fast failures.

Metrics

• Expose active_count, idle_count, wait_count, wait_time_ms, connection_create_rate, validation_failures, leak_warnings.

Implementation notes

• Use ConcurrentLinkedQueue for idle, AtomicInteger for size, ReentrantLock+Condition for waiters. Keep connection creation bounded to avoid resource storms.

Diagnosis steps

• Enable GC logging (-Xlog:gc*), capture heap/GC metrics (G1 pause times, frequency) and thread stacks during pause.
• Correlate latency spikes with GC logs and CPU/memory/alloc rate metrics.
• Use jcmd/jmap/jfr to inspect heap usage, object allocation rates, and live set.

Tuning & config

• Right-size heap: avoid too small (frequent GCs) or too large (long pauses). Tune -Xms/-Xmx to match observed live set + headroom.
• G1 tuning: adjust MaxGCPauseMillis, initiateHeapOccupancyPercent to trigger concurrent cycles earlier, increase G1NewSizePercent for throughput.
• Consider ZGC or Shenandoah for lower pause goals if JVM/OS supported and production-tested; they have concurrent compaction with sub-ms pauses but require Java builds supporting them.

Validation

• Create staging workload mirroring production allocation patterns; measure latency, GC pause percentiles, and throughput before/after changes using JFR and GC logs.
• Gradual rollout in prod with canary instances, monitor p99 latency and GC pause stats.

Best practices

• Reduce allocation churn: reuse buffers, prefer primitive arrays, off-heap caches if needed. Monitor metaspace and GC ergonomics. Document changes and keep rollback plan.