I’ve been thinking about file processing a lot lately. In our data-driven world, the ability to efficiently handle large files while keeping applications responsive isn’t just nice to have—it’s essential. That’s why I want to share how we can build high-performance file processing using Spring WebFlux and Java’s virtual threads.

Traditional approaches often struggle under heavy load. Have you ever seen your application slow to a crawl when processing multiple files simultaneously? The thread-per-request model simply doesn’t scale well for I/O-intensive operations. That’s where reactive programming and virtual threads come together to create something truly powerful.

Let me show you how this works in practice. We’ll start with a reactive controller that handles file uploads without blocking:

@RestController
@RequiredArgsConstructor
public class FileController {
    private final FileProcessor fileProcessor;

    @PostMapping(value = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
    public Mono<ResponseEntity<ProcessingResult>> uploadFile(
            @RequestPart("file") FilePart filePart) {
        return fileProcessor.processReactive(filePart)
                .map(result -> ResponseEntity.ok(result));
    }
}

But here’s where it gets interesting. While WebFlux handles the reactive streams beautifully, some operations like CSV parsing still benefit from virtual threads. Why force everything into reactive patterns when we can use the right tool for each job?

@Service
public class CsvProcessor {
    private final ExecutorService virtualThreadExecutor = 
        Executors.newVirtualThreadPerTaskExecutor();

    public CompletableFuture<List<Record>> parseCsvChunk(byte[] chunk) {
        return CompletableFuture.supplyAsync(() -> {
            try (CSVReader reader = new CSVReader(new InputStreamReader(
                 new ByteArrayInputStream(chunk)))) {
                return reader.readAll().stream()
                    .map(this::mapToRecord)
                    .collect(Collectors.toList());
            }
        }, virtualThreadExecutor);
    }
}

This hybrid approach gives us the best of both worlds. The reactive framework manages the overall flow and concurrency, while virtual threads handle the I/O-intensive parsing without blocking the event loop. It’s like having a well-coordinated team where each member plays to their strengths.

What happens when we need to process really large files? We can’t load everything into memory. Here’s how we handle streaming processing:

public Flux<ProcessingResult> processLargeFile(FilePart filePart) {
    return filePart.content()
        .buffer(1024)
        .flatMap(dataBuffer -> Mono.fromCallable(() -> 
            processDataBuffer(dataBuffer))
            .subscribeOn(Schedulers.boundedElastic()))
        .onErrorResume(this::handleProcessingError);
}

Monitoring becomes crucial in such systems. How do we know our implementation is actually performing better? We need proper metrics:

@Bean
public MeterRegistryCustomizer<MeterRegistry> metrics() {
    return registry -> registry.config().commonTags("application", "file-processor");
}

@Timed(value = "file.processing.time", description = "Time taken to process files")
public Mono<ProcessingResult> timedProcessing(FilePart filePart) {
    return fileProcessor.process(filePart);
}

The beauty of this approach lies in its scalability. We can handle hundreds of concurrent file processing requests without creating hundreds of platform threads. Virtual threads are lightweight, and WebFlux ensures we don’t waste resources waiting for I/O operations.

But what about error handling? In reactive systems, we need to be particularly careful:

public Flux<ProcessedRecord> processWithErrorHandling(Flux<DataBuffer> content) {
    return content.flatMap(buffer -> 
        Mono.fromCallable(() -> parseBuffer(buffer))
            .onErrorResume(e -> {
                log.error("Processing error", e);
                return Mono.empty();
            })
            .subscribeOn(Schedulers.boundedElastic())
    );
}

The combination of Spring WebFlux and virtual threads represents a significant shift in how we think about concurrency and I/O processing. It’s not about choosing one paradigm over another, but about using each where it shines brightest.

Have you considered how this approach might change your current file processing workflows? The potential for improved performance and resource utilization is substantial.

I’d love to hear your thoughts on this approach. Have you tried combining reactive programming with virtual threads? What challenges did you face? Share your experiences in the comments below, and don’t forget to like and share this article if you found it helpful.