Java Interview Deep Dive: Solving Real‑World Invoice System Challenges

First Round: Infrastructure & Core Components

Scenario: The interviewer asks the candidate to design the entry layer for a "C‑end user invoice issuance" scenario that must handle 100,000 concurrent requests and respond within 200 ms while guaranteeing data consistency.

Answer: Use Spring Boot + Spring Cloud Gateway as the API gateway, enable rate‑limiting and circuit‑breaking (e.g., Resilience4j). Apply async processing by returning an immediate "accepted" response and pushing the actual invoice workflow to Kafka. Pre‑warm user‑related data in Redis via Flyway scripts.

Cache penetration: Store a placeholder for missing keys (e.g., user:-1:) and use a Bloom filter to filter non‑existent IDs.

Cache snowball: Randomise expiration time, e.g., expire_time = 3600 + random(0, 600).

Kafka vs RabbitMQ: Kafka offers higher throughput, durable disk storage and consumer‑group scaling, making it more suitable for invoice‑issuing workloads.

Second Round: Multithreading & JVM Tuning

Scenario: Process 1,000 invoice tasks on an 8‑core, 16 GB machine.

Thread‑pool design: Use ThreadPoolExecutor with core size = 8, max size = 16, and an unbounded LinkedBlockingQueue to accommodate burst traffic.

JVM memory settings: -Xms10g -Xmx10g for heap, -XX:MetaspaceSize=512m for metaspace, and enable -XX:+UseG1GC with -XX:MaxGCPauseMillis=200 to keep GC pauses short.

OOM troubleshooting steps:

Inspect the error type ( OutOfMemoryError: Java heap space or Metaspace).

Generate a heap dump with

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof

and analyze with MAT.

Enable GC logging ( -Xloggc:/tmp/gc.log -XX:+PrintGCDetails) and review with GCViewer.

Take a thread snapshot ( jstack <pid> > thread.dump) to look for deadlocks or long‑running PDF generation threads.

Method Area vs Metaspace: The method area stores class metadata in the heap, while Metaspace (JDK 8+) stores it in native memory and can be sized via -XX:MetaspaceSize .

Third Round: Database & Cache Coordination

Scenario: Design storage and caching for invoice queries that must serve 1,000 QPS with < 50 ms latency and strong consistency.

Primary store: MySQL InnoDB table invoice (fields: id, user_id, order_id, amount, status).

Read replica: MySQL master‑slave replication using binlog + relay log for read‑write separation.

Local cache: Caffeine with maximumSize(10000) and expireAfterWrite(10, TimeUnit.MINUTES).

Distributed cache: Redis key pattern invoice:{id} storing JSON via Jackson.

Cache update strategy: Write‑after‑update (write to MySQL then publish a Kafka message to refresh Redis and Caffeine) and read‑through (fallback to MySQL on cache miss and populate caches).

Consistency: Allow eventual consistency with a 100 ms delay, but provide a "force refresh" flag for strong consistency when needed.

Redis outage handling: Degrade to MySQL read replica and trigger a Resilience4j CircuitBreaker on Redis failures.

MyBatis mapping: Use annotation @Select for simple queries and XML for complex dynamic SQL.

Fourth Round: Microservices & Message Queue

Scenario: Decouple invoice service from order service; guarantee no message loss and exactly‑once consumption.

Producer config: acks=all, retries=3, enable.idempotence=true; persist message ID in message_log table with status "unconfirmed".

Consumer config: Disable auto‑commit ( enable.auto.commit=false) and manually call consumer.commitSync() after successful processing.

Idempotence: Use business key (order ID) to check for existing invoice records ( SELECT COUNT(*) FROM invoice WHERE order_id = #{orderId}) before processing; protect concurrent processing with a Redis lock SETNX lock:order:{orderId} (TTL 5 s).

Broker reliability: Topic replication factor = 3, min.insync.replicas=2, and cross‑data‑center deployment.

Gateway & Nacos integration: Dynamic routing via Nacos instance list ( /nacos/v1/ns/instance/list) and hot‑update of route rules ( @RefreshScope + @Value("${routes}")).

Fifth Round: System Design & Business Modeling

Scenario: Design an end‑to‑end invoice system for an e‑commerce platform supporting C‑end users and B‑end merchants.

Layered architecture:

Access layer – Spring Cloud Gateway + Nacos for routing, rate‑limiting, and circuit‑breaking.

Business layer –

Invoice Service (core invoicing, PDF generation, status update).

Notification Service (email/SMS).

Query Service (invoice status lookup).

Data layer – MySQL master‑slave, Redis cluster, Kafka for decoupling.

Microservice decomposition: Separate Invoice, Notification, and Query services, each deployed with 3 replicas behind Nginx load‑balancer.

Data flow: User → Gateway → Invoice Service → MySQL → Kafka → Notification Service → MySQL; Query Service reads from Redis first, then MySQL on miss.

High‑availability: Service redundancy, MySQL backup + OSS snapshots, Redis 3‑master‑3‑slave cluster, Prometheus + Grafana monitoring with alerts (e.g., error rate > 1 %).

Challenges & lessons: Asynchronous design boosted QPS 5×, proper thread‑pool sizing reduced CPU usage from 90 % to 30 %, and idempotent messaging eliminated duplicate invoice issuance.

Answer Summaries

Entry layer – Spring Boot + Gateway + Kafka, async, cache pre‑heat, local message table.

Thread‑pool – core = 8, max = 16, LinkedBlockingQueue; JVM – 10 GB heap, 512 MB metaspace, G1 GC.

Storage – MySQL master/slave, Redis + Caffeine, write‑after‑update & read‑through, handling cache miss and Redis outage.

Messaging – Kafka acks = all, idempotent producer, manual offset commit, Redis lock for idempotence.

Design – layered microservice architecture, data flow, redundancy, monitoring, and performance tuning.

The whole interview showcases how to reason from problem definition, evaluate trade‑offs, select appropriate technologies, and validate solutions with concrete metrics and real‑world anecdotes.