Java Programming Questions

High-level architecture

• API layer (stateless Java services) → ingress load balancer → Order validation service → Inventory/Payment coordinator → Order write DB + async workers for fulfillment.

Partitioning & datastore

• Relational DB sharded by customer_id or order_id prefix (range or consistent-hash). Use per-shard leader for strong consistency. Read replicas for queries.
• Keep hot inventory counters in a strongly-consistent service: either co-locate inventory with shard or use distributed transactional store (sharded RDBMS with two-phase commit avoided).

Synchronous vs asynchronous

• Synchronously: reserve inventory and persist order in single shard transaction to ensure strong consistency. Charge payment synchronously or via reserved authorization.
• Asynchronously: fulfillment, notifications, analytics via Kafka.

Scaling & throughput

• Use front-tier autoscaling, pool DB connections per shard; horizontally scale Java workers; employ batching for writes where possible.
• Achieve 5k RPS by partitioning orders across many DB shards; ensure each shard handles subset <200ms writes.

Idempotency

• Idempotency keys per client stored in shard local table to dedupe retries.

Availability & metrics

• Measure p95/p99 latency, DB commit latency, tail latency, orders/sec, success rate. Use chaos tests and load tests.

Trade-offs & failure modes

• Strong consistency reduces throughput and increases cross-shard complexity. Sharding reduces contention but increases operational complexity. Payment/inventory partial failures require compensating actions and clear state machine.

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.

Core observability signals for a Java microservice

Metrics (library: Micrometer/Prometheus):

• http_requests_total{method, status}
• http_request_duration_seconds (histogram)
• db_query_duration_seconds{query}

Structured logs (library: Logback + Logstash encoder / SLF4J): include fields:

• service, level, timestamp
• request_id / trace_id
• user_id (masked) and error_code

Distributed traces (library: OpenTelemetry/Jaeger): span annotations:

• db.query (query name + duration)
• http.client_request (url, method)
• cache.hit (key, hit=true/false)

Avoid high-cardinality metrics by not tagging with user_id or raw IDs; use coarse buckets or sample rare tags. Use logs for high-cardinality identifiers, and apply scrubbing/PII redaction. Export tracing only for sampled requests to limit volume.

Compare OFFSET/LIMIT vs Keyset

• OFFSET/LIMIT: easy but becomes slow for large offsets because DB skips rows. Results unstable with concurrent inserts/deletes.
• Keyset (cursor) pagination: uses where clauses on indexed columns (e.g., id, created_at) to seek from last seen values; efficient and stable.

Example keyset SQL (posts sorted by created_at desc, id desc as tiebreaker)

SELECT id, created_at, title
FROM posts
WHERE (created_at, id) < ( :last_created_at, :last_id )
ORDER BY created_at DESC, id DESC
LIMIT 20;

Intuition: fetch posts older than last cursor.

Implementing in Java

• Spring Data: write @Query with the above SQL and pass last cursor params; return Page-like results.
• Manual JDBC/JPA: maintain lastCreatedAt and lastId in client; build query dynamically.

Trade-offs when sorting by multiple columns

• Need composite index on (created_at DESC, id DESC) to be efficient.
• Keyset cannot easily jump to arbitrary page number; suitable for 'Next'/'Prev' navigation.
• For complex sort (non-unique combos), include deterministic tiebreaker (PK) to maintain stable ordering.

Public API (example)

• V get(K key)
• void put(K key, V value, Duration ttl, Consumer<V> onEvict)
• void remove(K key)

Implementation outline

• Use ConcurrentHashMap<K, Node> for O(1) lookup.
• Maintain LRU order using a concurrent-friendly doubly-linked list or a striped LinkedHashMap; or better, use Caffeine which implements windowed LRU and is highly concurrent.
• Each Node holds value, expireAt, and references for eviction list. Use a background cleaner to remove expired entries and call eviction callback asynchronously.
• For thread-safety update operations: use CAS on Node references and small synchronized blocks only for list pointer updates or use lock-striping to reduce contention.

TTL & eviction callback

• On get, check expiry; if expired, remove and call callback.
• On put, if over capacity, evict least-recently-used node and trigger callback.

Correctness & tests

• Concurrency tests: many-thread get/put/remove verifying size bounds, no lost entries.
• Eviction tests: validate LRU order under access patterns.
• TTL tests: ensure entries expire roughly after TTL and callback invoked.

Recommendation

• Prefer Caffeine for production: offers O(1), TTL, eviction listeners, and proven concurrency and performance.