In a high-throughput ingestion service, would you build it around WatchService or a different mechanism? Discuss the trade-offs and how you'd make WatchService production-grade.
answer
- WatchService = best-effort notifications, not durable
- OVERFLOW + downtime = lost events → need reconciliation
- Hybrid: fast event path + periodic re-scan safety net
- Idempotent processing (hash or move-to-done)
- Prefer a durable queue/API when you control the producer
basics
~20 sWatchService is great for low-to-moderate change rates because it's efficient and event-driven. For very high throughput or strict reliability, you usually pair it with periodic reconciliation (or replace it), because it can drop events (OVERFLOW), behaves differently per OS, and isn't recursive. The robust design is event-driven for speed plus a safety net that re-scans.
solid answer
~50 sWatchService is the right default for reacting to filesystem changes at modest rates: it's efficient (native-backed, no busy polling) and low-latency. But for a high-throughput, must-not-lose-files ingestion service I wouldn't trust it alone. It can lose events (OVERFLOW under bursts), is single-level so recursion is hand-rolled, varies by platform (native on Linux/Windows, historically polling on macOS), and consumes finite OS watches (inotify limits) on large trees. The production pattern is a hybrid: use WatchService as the fast path for low latency, but back it with periodic reconciliation that lists the directory and diffs against processed-state to catch anything dropped, and make processing idempotent (e.g. key off a content hash or move files to a 'processing'/'done' folder) so reprocessing is harmless. Keep the watch loop thin and offload work to an executor to avoid overflow. If the source can push notifications (an upload API, a message queue), prefer that over watching shared disk entirely, since a queue gives durability and backpressure that a directory cannot.
go deeper
Knows WatchService is event-driven and more efficient than polling, and that it can sometimes miss events.
Lists concrete limitations (OVERFLOW, no durability, single-level, platform variance) and the idea of combining it with a re-scan.
Designs a hybrid fast-path-plus-reconciliation system with idempotent processing, debouncing, offloaded work, and OS-limit awareness.
Frames the choice by delivery guarantees, treats WatchService as a latency optimization rather than a source of truth, weighs durable queues/APIs vs file-drop integration, and designs for idempotency, backpressure, crash recovery, and operational monitoring.
## Framing the decision The question is really about **delivery guarantees**. WatchService offers **best-effort, at-most-once-ish** delivery of filesystem change *notifications* — it can and will drop events under load (OVERFLOW), and it tells you nothing durable: if your process is down when a file lands, you simply never get that event. An ingestion service that must process every file therefore cannot rely on notifications alone as its source of truth. ## Strengths of WatchService - **Efficiency / low latency.** Native OS backing (inotify on Linux, ReadDirectoryChangesW on Windows) means the kernel pushes notifications; an idle directory costs nothing and you react in milliseconds. No busy polling. - **Simplicity for modest needs.** For a config-reload watcher or a low-volume inbox, the whole thing is a small loop. - **Standard, no dependencies.** Part of the JDK since Java 7. ## Weaknesses that matter at scale - **Event loss (OVERFLOW).** Bursts or a slow consumer overflow the buffer; lost events are unrecoverable from the stream. - **No durability.** Notifications are ephemeral. Downtime = missed files. There is no replay. - **Single-level.** Tree watching is hand-rolled, with create/populate races, symlink-cycle and cleanup concerns. - **Platform variance.** Native on Linux/Windows; historically a polling fallback on macOS (higher latency, more CPU). Behavior and event coalescing differ across OSes — e.g. a single save may yield one or several MODIFY events. - **Resource limits.** inotify caps the number of watches/instances; large trees can exhaust them and fail to register. - **No backpressure.** A directory can't push back when you're overwhelmed; a queue can. ## The production-grade hybrid For a service that must be both fast and reliable: 1. **Fast path — WatchService for latency.** React promptly to new files. Keep the loop thin: between `take()` and `reset()`, do nothing but enqueue the path to a worker `ExecutorService`. This minimizes overflow risk. 2. **Safety net — periodic reconciliation.** On a timer (and on every OVERFLOW), list the directory and diff it against a durable record of what's been processed. Anything present-but-unprocessed gets picked up. This closes the gaps from dropped events and downtime. 3. **Idempotent processing.** Because both paths (and OVERFLOW recovery) can present the same file more than once, processing must be safe to repeat: dedupe on a content hash or a processed-files store, or atomically **move** the file from `inbox/` to `processing/` then `done/` so it's claimed exactly once and crash-recoverable. 4. **Debounce writes.** A file may still be being written when CREATE fires; wait for size/mtime to stabilize, or require an atomic rename of a fully-written temp file into the watched dir, so you never read a half-written file. 5. **Offload + bound concurrency.** A bounded worker pool/queue gives you backpressure the filesystem can't. 6. **Tune and monitor OS limits** (inotify watches) and alert on registration failures and OVERFLOW frequency. ## When to skip WatchService entirely If you control the producer, an **explicit push** is strictly better: an upload API or a **message queue** (Kafka, SQS, RabbitMQ) gives durability, replay, ordering, and backpressure — properties a shared directory fundamentally lacks. Watching a network/shared filesystem is especially fraught (NFS notifications are unreliable). In those cases, treat the directory as a last-resort interop mechanism and lean on reconciliation, or move off file-drop integration altogether. ## The principal-level takeaway Choose by required guarantee, not by convenience. WatchService is an *optimization for latency*, not a *source of truth*. Design the source of truth to be the durable directory state (reconciliation) or a durable queue; let WatchService make the common case fast. Make the whole thing idempotent so that the inevitable double-delivery and replay are non-events.
- Why can't WatchService be the sole source of truth for a must-not-lose-files importer?It delivers ephemeral, best-effort notifications: it drops events under load (OVERFLOW) and delivers nothing for files that arrive while the process is down, with no replay — so files can be silently missed without an independent reconciliation pass.
- How do you keep file processing safe when the same file may be delivered more than once?Make processing idempotent: dedupe on a content hash or a processed-files record, or atomically move the file through inbox→processing→done so it's claimed exactly once and reprocessing is harmless.
- When would you avoid WatchService altogether?When you control the producer and need durability/replay/backpressure — use an upload API or a message queue instead; also avoid relying on it over unreliable network filesystems like NFS.
WatchService is a smoke alarm: great for instant alerts, but you still do scheduled inspections (reconciliation) because an alarm can miss things or be unplugged while you're away.
saying these in an interview costs you the question
- Treating WatchService notifications as a durable, guaranteed-delivery source of truth
- Doing heavy processing inline in the watch loop (causing overflow)
- No reconciliation/safety net, so dropped events or downtime lose files
- Reading files before they finish being written (no debounce/atomic-rename)
- Relying on directory watching over NFS or other unreliable shared filesystems