Faith & Code | Reflections by Errong

ParallelStream vs Virtual Threads in Java 21: What Actually Works for Database Workloads Java offers multiple ways to parallelize work, but not all concurrency models are suitable for database-heavy workloads. In modern systems, especially with large batch processing (e.g., 10,000–50,000 IDs), choosing the right model can drastically change performance. This article compares ParallelStream and Virtual Threads (Java 21) using a real-world scenario: batch database queries in Oracle. 🧠 The Problem: Large Batch Database Queries A common backend scenario is fetching data using large ID lists: Example: - 40,000 transaction IDs - Chunked into 1,000 per query - ~40 database queries executed The key question becomes: how do we execute these 40 queries efficiently? ⚙️ Approach 1: ParallelStream IntStream.range(0, batchCount) .parallel() .mapToObj(i -> repository.query(batch)) How it works Uses ForkJoin common pool Thread count ≈ number of CP...

How to Optimize a Slow JPA Query Processing 40K+ IDs (Real Performance Tuning Guide) Handling large datasets efficiently is one of the most common challenges in backend engineering. In this post, I’ll walk through how a query processing 40,000+ IDs went from ~24 seconds down to a few seconds using practical optimization techniques. All domain-specific details have been intentionally removed to focus purely on reusable engineering patterns. 📉 The Problem A service fetches data using a JPA query with a large IN clause and joins between tables: SELECT new SomeDto( A.primaryId, A.field1, A.field2, B.field3, C.metric1, C.metric2 ) FROM EntityA A LEFT JOIN A.relatedEntity B LEFT JOIN EntityC C ON C.refId = A.primaryId WHERE A.primaryId IN :ids Even with chunking (~900 IDs per query), total execution time was around 24 seconds . 🚨 Root Causes Unoptimized JOIN conditions Missing database indexes Sequential query execution ORM (JPA) over...

How We Optimized a Spring Boot Pagination Query by 36× (From 1.8 Minutes to 3 Seconds) In high-traffic backend systems, slow database queries are often the hidden bottleneck that quietly kills performance. In our case, a paginated query powering a reporting API was taking 1.8 minutes to respond under load. After optimization, we reduced it to ~3 seconds . 36× faster ~97.2% less execution time ~3500% performance improvement Here’s how we did it — and the key lessons you can apply immediately. 🧱 The Problem: Slow Pagination Query We had a Spring Data JPA query backing a paginated API. It involved multiple filters, joins, and was returning a large dataset. Original issues: Full entity loading Heavy object graph hydration Unnecessary columns fetched Inefficient filtering logic Expensive pagination count The database schema (simplified and anonymized) looked like this: TABLE txn_line ( line_id BIGINT, order_id BIGINT, product_code ...