DEV Community: Machine coding Master

Surviving MatchException: The Sealed Hierarchy Landmine in Java 21+ Microservices

Machine coding Master — Thu, 22 Oct 2026 07:56:21 +0000

Surviving MatchException: The Sealed Hierarchy Landmine in Java 21+ Microservices

Teams are aggressively migrating event schemas to Java 21+ sealed interfaces and record patterns, celebrating the death of boilerplate visitor code right until their first rolling deployment triggers an outage. When a producer publishes a new permitted subtype to a shared artifact, downstream consumers running the previous client version fail at runtime with a catastrophic java.lang.MatchException.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

Why Most Developers Get This Wrong

Confusing compile-time exhaustiveness with binary compatibility: javac validates exhaustive pattern switches against the hierarchy known at compile time, omitting a fallback branch and emitting a synthetic MatchException invocation if an unexpected subtype arrives at runtime.
Sharing domain models over the wire: Exposing internal sealed hierarchies directly in shared SDKs couples deployment lifecycles, breaking the independence of microservices during rolling upgrades or canary releases.
Assuming deserialization guarantees safety: JSON parsers like Jackson might successfully deserialize a newly added permitted record if configured loosely, passing the unhandled subtype directly into your pattern switch.

The Right Way

Decouple wire-level consumption from exhaustive pattern switching by treating cross-service sealed hierarchies as open at the boundary.

Sacrifice exhaustiveness at ingestion boundaries: Intentionally include a fallback pattern (case OrderEvent unknown -> ...) or a standard default to swallow version skew gracefully instead of crashing the worker thread.
Model an explicit fallback subtype: Introduce an UnknownEvent(String payload) implements OrderEvent record into the sealed hierarchy, paired with a custom deserializer that traps unrecognized type tags.
Enforce strict consumer isolation: Translate external payloads into bounded-context-specific sealed types rather than sharing the exact same Java artifact across service boundaries.

Show Me The Code

// Boundary consumer: Neutralize compiler-synthesized MatchException
public void handleIncomingEvent(OrderEvent event) {
    switch (event) {
        case OrderCreated created -> processCreated(created);
        case OrderCancelled cancelled -> processCancelled(cancelled);
        // CRITICAL: Prevents runtime crash when producer adds OrderRefunded 
        // before this consumer updates its shared domain library
        case OrderEvent unknown -> {
            meterRegistry.counter("events.unhandled.version_skew").increment();
            deadLetterQueue.send(unknown);
        }
    }
}

Key Takeaways

Sealed pattern matching is exceptional for domain modeling within a single deployable unit, but dangerous across distributed boundaries subject to independent release cadences.
java.lang.MatchException is a runtime failure mode generated by the compiler; binary compatibility does not equal semantic exhaustiveness.
Always include an explicit catch-all pattern on switches operating on cross-service domain events to survive asynchronous cluster upgrades.

Stop Routing Reads to Primary: Building Causal Consistency in Java with Postgres LSN Tokens

Machine coding Master — Mon, 19 Oct 2026 08:02:54 +0000

Stop Routing Reads to Primary: Building Causal Consistency in Java with Postgres LSN Tokens

Falling back to your primary database for reads right after a mutation is a lazy architectural crutch that kills your write capacity at scale. In 2026, if you aren't using causal session tokens across your edge and read replicas, you're needlessly setting money on fire with oversized primary instances.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

Why Most Developers Get This Wrong

Arbitrary TTL pinning: Routing all session reads to the primary for "5 seconds after a write" blindsides your master node during traffic spikes and wastes up to 40% of replica capacity.
Ignoring database watermarks: Engineers treat replication lag as an unpredictable mystery instead of querying exact write-ahead positions (pg_current_wal_lsn() in Postgres or GTID in MySQL).
Over-engineering with distributed locks: Reaching for heavy coordination layers like Raft or Redis locks when monotonic causal consistency (Read-Your-Own-Writes) is all the end-user requires.

The Right Way

Capture the commit log sequence number on writes, return it to the client as an HTTP response header, and enforce replica watermarks on subsequent reads.

Extract the engine's log sequence number (e.g., Postgres LSN) immediately within your mutation transaction.
Echo the token back to the client via an HTTP header (e.g., X-Causal-Token: 0/16B3748).
Pass the token back in subsequent GET requests and route to a replica pool managed by a Spring AbstractRoutingDataSource.
Check replica state against the token using a low-latency cached watermark; fall back to the primary only when lag hedging bounds (e.g., 25ms) are exceeded.

Show Me The Code

public class CausalReadDataSourceRouter extends AbstractRoutingDataSource {
    private final ReplicaWatermarkTracker watermarkTracker;

    @Override
    protected Object determineCurrentLookupKey() {
        String requiredLsn = CausalContextHolder.getRequiredLsn();
        if (requiredLsn == null) {
            return DataSourceType.REPLICA; // Cold reads bypass lag verification
        }

        // Fast in-memory check against background-polled pg_last_wal_replay_lsn()
        boolean replicaCaughtUp = watermarkTracker.isReplayed(requiredLsn);
        return replicaCaughtUp ? DataSourceType.REPLICA : DataSourceType.PRIMARY;
    }
}

Key Takeaways

Replicas are for reads: Pinning entire user sessions to the primary defeats the purpose of horizontal scaling.
LSN tokens enable true causal consistency: The client tracks their own timeline without imposing global linearizability bottlenecks on your persistence tier.
Hedging protects latency: Always implement a fast fallback threshold so replication spikes degrade to primary reads rather than surfacing connection timeouts.

Stop Hallucinating Footnotes: Implementing Claude's Native Citations with Spring AI and Java 26

Machine coding Master — Sun, 18 Oct 2026 07:23:52 +0000

Stop Hallucinating Footnotes: Implementing Claude's Native Citations with Spring AI and Java 26

Enterprise legal teams in 2026 will immediately reject your RAG pipeline if your citations rely on an LLM hallucinating bracketed markdown footnotes like [1]. Anthropic's native citations API solves this compliance nightmare by shifting source attribution from stochastic text generation to deterministic, byte-accurate document block references.

Why Most Developers Get This Wrong

Begging Claude via system prompts to "append markdown footnotes with source URLs," which fails catastrophically under token pressure and complex multi-document context.
Collapsing streaming citation events into the standard text buffer, forcing frontend teams to build fragile regex parsers to reconstruct source attributions.
Ignoring Anthropic's native char_location metadata, throwing away verifiable byte-offset audit trails that legal compliance engines require.

The Right Way

Feed reference context through Anthropic's native document content blocks with citations enabled, streaming raw citation deltas directly into strongly typed Java 26 records.

Configure context payloads as explicit document blocks with citations: { enabled: true } in your Spring AI Anthropic request customizers.
Intercept low-level Server-Sent Events (SSE) to isolate citation_delta payloads from standard content_block_delta tokens.
Map exact char_location spans (start_char_index, end_char_index) back to your primary database keys using Java 26 pattern matching.
Stream citations as side-channel metadata events over your reactive SSE pipe to keep UI token rendering instant and clean.

Show Me The Code

public record DocumentRef(String docId, int startChar, int endChar, String citedText) {}

// Unpack streaming citation delta events using Java 26 record deconstruction
public DocumentRef resolveCitationDelta(AnthropicStreamChunk chunk) {
    return switch (chunk) {
        case CitationDelta(var id, CharLocation(var start, var end), var text) ->
            new DocumentRef(id, start, end, text);
        case ContentBlockDelta ignored -> null;
        default -> null;
    };
}

Key Takeaways

Kill the footnote prompts: native citations provide mathematical source grounding that enterprise compliance teams will actually sign off on.
Treat citations as first-class streaming metadata events, completely decoupled from generation text buffers.
Use Java 26 record patterns to cleanly unpack nested char_location boundaries into domain-safe audit trail records without boilerplate.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Stop AI NullPointerExceptions: Compile-Time Zero-NPE Java with JSpecify, NullAway, and Claude Code

Machine coding Master — Sat, 17 Oct 2026 07:09:43 +0000

Stop AI NullPointerExceptions: Compile-Time Zero-NPE Java with JSpecify, NullAway, and Claude Code

AI agents generate Java at blistering speeds, but LLMs still hallucinate null safety by littering codebases with redundant null-checks instead of enforcing structural invariants. If your agentic workflow in 2026 isn't hard-gated by strict compile-time diagnostics, you are simply automating the generation of production NullPointerExceptions.

Why Most Developers Get This Wrong

Relying on fragmented annotations: LLMs mix JSR-305, SpotBugs, and JetBrains annotations indiscriminately, breaking static analysis across modular boundaries.
Overusing Optional<T>: Models default to wrapping internal domain fields and method parameters in Optional, degrading memory efficiency and polluting domain models.
Treating the LLM as a typist, not a compiler loop: Developers still manually review AI-generated diffs instead of forcing the agent to resolve raw AST compiler errors autonomously.

The Right Way

Make non-null the default and wire deterministic compiler errors into Claude Code's execution loop.

Enforce standard JSpecify (org.jspecify:jspecify:1.0.0) across your codebase to give LLMs a single, unambiguous annotation grammar.
Mark entire packages with @NullMarked, forcing the compiler to treat every unannotated type as strictly non-null.
Wire Uber's NullAway into Error Prone with TreatWarningsAsErrors enabled to fail builds immediately upon any contract violation.
Run Claude Code CLI inside a closed feedback loop (claude "fix NullAway errors after running ./gradlew compileJava"), allowing the agent to self-correct based on exact line-and-column diagnostic outputs.

I built javalld.com while prepping for senior roles — complete LLD problems with execution traces, not just theory.

Show Me The Code

// package-info.java: @org.jspecify.annotations.NullMarked
package com.payment.core;

import org.jspecify.annotations.Nullable;

public final class SettlementService {
    // NullAway halts compilation if order is null, or if nullable ledger is dereferenced unsafely
    public Receipt settle(Order order, @Nullable AuditLedger ledger) {
        String txId = order.transactionId(); // Guaranteed non-null by @NullMarked
        long auditCode = (ledger != null) ? ledger.record(txId) : 0L; 
        return new Receipt(txId, auditCode);
    }
}

Key Takeaways

Standardize on JSpecify: Stop letting AI guess between checker frameworks; standardize on @NullMarked and @Nullable.
Fast diagnostics win: NullAway adds single-digit millisecond overhead to compilation, making it fast enough for real-time agent loops.
Close the agent loop: Feed raw javac and NullAway errors directly back into Claude Code so it fixes its own nullability violations before code ever hits git.

Thread-Safe Counter in Java: Fix Your First Concurrency Bug in Machine Coding

Machine coding Master — Fri, 16 Oct 2026 07:30:09 +0000

Thread-Safe Counter in Java: Fix Your First Concurrency Bug in Machine Coding

During high-pressure machine coding interviews, seemingly trivial building blocks are where candidates quietly introduce race conditions that fail multi-threaded verification tests. A standard counter looks deceptively simple, but failing to handle concurrent mutation immediately signals a lack of production-grade Java depth to senior interviewers.

The Mistake Most Candidates Make

Assuming count++ is an atomic instruction; at the bytecode level, it is a non-atomic read-modify-write sequence (getfield, iadd, putfield).
Declaring volatile int count = 0; under the false impression that visibility guarantees atomicity; it syncs cache lines across CPU cores but does not stop interleaved updates.
Defaulting to heavy synchronized blocks around simple scalar updates, introducing unnecessary lock contention and context-switching overhead.

The Right Approach

Treat state mutations as atomic transactions that guarantee both memory visibility and uninterrupted execution across threads.
AtomicInteger, LongAdder, ReentrantLock
Lock-free primitives leverage hardware-level Compare-And-Swap (CAS) instructions to eliminate race conditions without suspending threads.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

The Key Insight (Code)

import java.util.concurrent.atomic.AtomicInteger;

public class ThreadSafeCounter {
    private final AtomicInteger count = new AtomicInteger(0);

    // Lock-free atomic increment using hardware CAS
    public int increment() {
        return count.incrementAndGet();
    }

    public int get() {
        return count.get();
    }
}

Key Takeaways

count++ is non-atomic; concurrent threads will interleave during execution, leading to lost increments and non-deterministic results.
volatile fixes the cache visibility problem, but it cannot make compound read-modify-write operations thread-safe.
Use AtomicInteger for standard thread-safe counting, and consider LongAdder for high-throughput write-heavy scenarios to reduce CAS contention.

Full working implementation with execution trace available at https://javalld.com/learn/thread-counter

Stop Restarting Failed Loops: Resumable ReAct Agents with Spring AI State Checkpointing

Machine coding Master — Sun, 11 Oct 2026 09:14:25 +0000

Stop Restarting Failed Loops: Resumable ReAct Agents with Spring AI State Checkpointing

Your ReAct agent just burned 45,000 tokens navigating an 8-step enterprise workflow, only to blow up on a transient downstream 503 at step 7. Catching that exception and restarting the prompt chain from step zero isn't just terrible engineering—it is lighting your inference budget on fire.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

Why Most Developers Get This Wrong

Treating agents like stateless HTTP calls: Wrapping ChatClient inside a basic @Retryable loop forces the model to regenerate every prior thought and action when a tool flakes out.
Side-effect amnesia: Retrying an agent from scratch without an idempotent journal causes non-idempotent tools (like payment authorization or ticket creation) to double-execute.
In-memory state reliance: Storing the Thought-Action-Observation trace purely in JVM memory guarantees unrecoverable drops on container redeploys or out-of-memory kills.

The Right Way

Decouple reasoning from tool execution by persisting an append-only state journal at every step of the ReAct cycle.

Implement an explicit StateCheckpointRepository that commits the AgentContext and conversation trace immediately after every tool observation.
Attach an idempotency key derived from (agentRunId, stepIndex, toolName) to every external side effect.
Resume failed workflows deterministically by rehydrating the checkpointed history into ReActAgent rather than re-prompting the initial goal.

Show Me The Code

Configure a durable, checkpoint-aware ReAct workflow in Spring AI:

@Bean
public AgentExecutor orderRecoveryAgent(ChatClient.Builder builder, VectorCheckpointStore store) {
    return ReActAgent.builder(builder.build())
        .tools(inventoryTool, paymentTool, logisticsTool)
        .checkpointStore(store) // Persists state to PostgreSQL after every step
        .onStepFailure((context, failure) -> {
            log.error("Step {} failed for run {}. Checkpointing for resume.", 
                context.getStepIndex(), context.getRunId(), failure);
            return RecoveryStrategy.SUSPEND; // Freezes state, releases thread
        })
        .idempotencyKeyGenerator(ctx -> ctx.getRunId() + ":" + ctx.getStepIndex())
        .build();
}

Key Takeaways

Never restart from step zero: Save intermediate Thought/Action/Observation vectors so transient failures only cost you the failed step's tokens.
Enforce tool idempotency: Key all side-effecting operations by agent execution ID and step index to make re-entry safe.
Treat agents as distributed state machines: If your framework doesn't survive a JVM crash mid-loop, it is not production-ready.

Kill the Visitor Pattern: Refactoring Domain ASTs with Java 21 Sealed Hierarchies

Machine coding Master — Sat, 10 Oct 2026 08:53:55 +0000

Kill the Visitor Pattern: Refactoring Domain ASTs with Java 21 Sealed Hierarchies

For decades, the Visitor pattern was our only escape hatch for adding operations to object structures without mutating them. In modern backend engineering, clinging to double-dispatch boilerplate across your domain evaluators and AST engines is pure technical debt—sealed hierarchies and record patterns have rendered it completely obsolete.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

Why Most Developers Get This Wrong

Treating the Gang of Four Visitor pattern as an untouchable standard, forcing every new domain node to implement accept(NodeVisitor v) and fragmenting traversal logic across dozens of files.
Reverting to manual instanceof checks with ugly if/else ladders instead of trusting the compiler to guarantee total coverage.
Leaving intermediate record extractors in place rather than leveraging nested pattern deconstruction to unwrap complex payloads in a single expression.

The Right Way

Model your domain engine as an algebraic data type with sealed interfaces, then evaluate nodes using exhaustive switch expressions and nested deconstruction.
Declare the root node as sealed interface Node permits ... to turn your hierarchy into a closed, compiler-enforced contract.
Delete all accept(), visit(), and Visitor classes across the entire codebase—zero double-dispatch overhead.
Match on structural shapes directly in switch arms, extracting nested values without intermediate local variables.
Eliminate runtime default branches: adding a new record type to the sealed hierarchy breaks the build at compile time wherever an evaluator exists.

Show Me The Code

sealed interface Expr permits Const, Add, Neg {}
record Const(double val) implements Expr {}
record Add(Expr left, Expr right) implements Expr {}
record Neg(Expr expr) implements Expr {}

static double eval(Expr expr) {
    return switch (expr) {
        case Const(var val) -> val;
        case Add(Const(var l), Const(var r)) -> l + r; // nested deconstruction
        case Add(var l, var r) -> eval(l) + eval(r);
        case Neg(var e) -> -eval(e);
    };
}

Key Takeaways

Double-dispatch is dead: pattern matching gives you clean separation of data and behavior without recursive indirection.
Exhaustiveness is safer than visitor contracts: javac catches missing edge cases at compile time without relying on runtime fallbacks.
Nested record patterns collapse tree transformations: complex AST evaluation logic drops from hundreds of boilerplate lines down to declarative switch blocks.

Java Machine Coding: Print Sequence with Multiple Threads

Machine coding Master — Fri, 09 Oct 2026 09:31:03 +0000

Java Machine Coding: Print Sequence with Multiple Threads

Printing a strictly ordered sequence using multiple threads is a classic FAANG concurrency screen because it instantly exposes whether you grasp inter-thread coordination. Candidates who struggle typically fall back on brittle busy-waiting loops or create deadlocks under high thread contention.

The Mistake Most Candidates Make

Spinning on volatile variables: Relying on shared flags inside tight while loops, burning 100% CPU core capacity through busy-waiting.
Overusing notifyAll() on single intrinsic locks: Waking up every dormant thread simultaneously, causing a thundering herd problem where $N-1$ threads immediately go back to sleep.
Missing spurious wakeup guards: Using if instead of while around wait checks, leading to corrupt execution order when the JVM awakens a thread unpredictably.

The Right Approach

Core mental model: Model execution as an explicit turn-based state machine where each worker blocks on its own condition variable until specifically signaled by its predecessor.
Key entities/classes: ReentrantLock, Condition[], and a shared currentTurn state integer.
Why it beats the naive approach: Target-signaling dedicated condition queues yields $O(1)$ wakeups and completely prevents CPU burn and contention overhead.

The Key Insight (Code)

lock.lock();
try {
    // 1. Guard against spurious wakeups
    while (currentTurn != threadId) {
        conditions[threadId].await();
    }
    // 2. Perform work and advance state
    System.out.print(number + " ");
    currentTurn = (currentTurn + 1) % totalThreads;
    // 3. Wake ONLY the next thread in sequence
    conditions[currentTurn].signal();
} finally {
    lock.unlock();
}

Key Takeaways

Always wrap .await() calls in a while loop check to preserve invariants against JVM spurious wakeups.
Array-based Condition references allow deterministic, point-to-point signaling between arbitrary thread topologies.
Update sequencing state strictly within the critical section prior to firing .signal() to ensure atomicity.

If you're prepping for interviews, I've been building javalld.com — real machine coding problems with full execution traces.

Full working implementation with execution trace available at https://javalld.com/learn/print-sequence

Java & AI: What Developers Need to Know

Machine coding Master — Sun, 04 Oct 2026 08:41:57 +0000

Stop Context Starvation: Implementing Parent Document Retrieval in Spring AI

Uniform 512-token chunking in production RAG pipelines is dead; it either dilutes vector search precision or starves your LLM of surrounding context. By adopting parent-child retrieval in Spring AI with pgvector, you decouple needle-in-a-haystack search granularity from generation context.

Why Most Developers Get This Wrong

Embedding massive chunks: Stuffing 1,000-token blocks into PgVectorStore hoping embeddings retain fine-grained facts—cosine similarity inevitably washes out.
Feeding micro-chunks directly to the LLM: Ingesting 128-token snippets yields high search precision, but passing isolated sentence fragments causes the LLM to hallucinate from missing context.
Over-engineering with extra infrastructure: Spinning up separate graph databases or external key-value caches instead of leveraging relational metadata linking already available in PostgreSQL.

The Right Way

Decouple retrieval units from synthesis units by indexing micro-chunks containing a parent_id metadata pointer, then hydrating the full parent document before building your prompt.

Split hierarchically: Generate large parent sections (1,024 tokens) for synthesis and split them into child micro-chunks (128 tokens) for vector indexing.
Link via metadata: Inject the parent's primary key into each child Document using Spring AI's doc.getMetadata().put("parent_id", parentId).
Query pgvector with children: Execute vector similarity searches strictly against the child embeddings for maximum retrieval sensitivity.
Expand context before generation: Map child hits back to unique parent IDs and fetch the full parents via standard relational queries before calling ChatClient.

Show Me The Code


java
public List<Document> retrieveWithParentContext(String query) {
    // 1. High-precision similarity search on 128-token child embeddings
    List<Document> childHits = vectorStore.similaritySearch(
        SearchRequest.builder().query(query).topK(5).similarityThreshold(0.78).build()
    );

    // 2. Extract unique parent UUIDs from Spring AI Document metadata
    Set<UUID> parentIds = childHits.stream()
        .map(doc -> UUID.fromString(doc.getMetadata().get("parent_id").toString()))
        .collect(Collectors.toSet());

    //

The Shallow Immutability Trap: Hardening Java 21 Records for Virtual Threads

Machine coding Master — Sat, 03 Oct 2026 08:35:33 +0000

The Shallow Immutability Trap: Hardening Java 21 Records for Virtual Threads

Virtual threads allow us to spawn millions of concurrent tasks with trivial overhead, but teams are quietly sabotaging their services by assuming records provide deep immutability. Java records only make component references final; passing mutable collections through them into massive concurrent fan-outs guarantees silent data corruption.

Why Most Developers Get This Wrong

Confusing shallow field immutability with deep thread safety: A record UserPayload(List<String> roles) prevents reassignment of roles, but any virtual thread can still call roles.add() concurrently without triggering a compile-time warning.
Blinded by structured concurrency: Launching thousands of subtasks via StructuredTaskScope while passing around unhardened records leads to unsynchronized, cross-thread mutations on shared heap structures.
Trusting generated accessors: Standard record accessors return direct object references, completely bypassing encapsulation and leaking internal mutable state to unpredictable caller threads.

The Right Way

Enforce strict, deep immutability at construction time so records remain genuinely read-only across arbitrary virtual thread boundaries.

Use compact canonical constructors to replace incoming collection references with frozen copies via List.copyOf(), Set.copyOf(), or Map.copyOf().
Reject or defensively copy mutable components (such as Date, arrays, or custom domain POJOs) before the instance finishes instantiation.
Avoid exposing raw, mutable third-party objects inside records—wrap them in unmodifiable adapters or domain primitives.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

Show Me The Code

Here is how to properly harden a record against concurrent mutation across millions of virtual threads:

public record OrderBatch(String batchId, List<UUID> orderIds, Instant createdAt) {
    // Compact canonical constructor enforces deep immutability
    public OrderBatch {
        Objects.requireNonNull(batchId, "batchId cannot be null");
        Objects.requireNonNull(createdAt, "createdAt cannot be null");

        // List.copyOf handles null-checking of elements and guarantees an unmodifiable list
        orderIds = List.copyOf(orderIds);
    }
}

If an external virtual thread attempts orderBatch.orderIds().add(newId), it immediately fails fast with an UnsupportedOperationException instead of corrupting shared memory.

Key Takeaways

Records guarantee shallow immutability only; final references to mutable objects are not thread-safe.
List.copyOf() inside a compact constructor provides instant, fail-fast protection against concurrent modification bugs.
As virtual thread counts scale into the millions, defensive copying at record boundaries is mandatory for state integrity.

Reader-Writer Lock in Java: Solving the Library Problem in LLD

Machine coding Master — Mon, 28 Sep 2026 08:54:57 +0000

Reader-Writer Lock in Java: Solving the Library Problem in LLD

In Java concurrency and machine coding rounds, synchronizing read-heavy systems with coarse-grained locks is an immediate red flag. The classic "Library Problem"—where thousands browse books while librarians infrequently update the catalog—tests whether you understand lock contention and read-write access asymmetry.

The Mistake Most Candidates Make

Slapping synchronized or a plain ReentrantLock across all operations, serializing every reader and collapsing system throughput to a single thread.
Ignoring writer starvation by defaulting to unfair lock policies where an endless stream of readers completely starves pending writes.
Omitting proper resource cleanup by failing to place unlock() inside finally blocks, leading to permanent lock leaks when runtime exceptions occur.

The Right Approach

Core mental model: Multiple readers can safely access shared state concurrently, but a writer demands absolute, exclusive ownership before mutating data.
Key entities/classes: ReadWriteLock, ReentrantReadWriteLock, Lock, CatalogManager.
Why it beats the naive approach: It eliminates reader-on-reader lock contention entirely while maintaining strict consistency boundaries during updates.

Shameless plug: javalld.com has full LLD implementations with step-by-step execution traces — free to use while prepping.

The Key Insight (Code)

public class BookCatalog {
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock(true);
    private final Lock readLock = rwLock.readLock(), writeLock = rwLock.writeLock();
    private final Map<String, Book> books = new HashMap<>();

    public Book get(String id) {
        readLock.lock();
        try { return books.get(id); }
        finally { readLock.unlock(); }
    }

    public void put(Book book) {
        writeLock.lock();
        try { books.put(book.id(), book); }
        finally { writeLock.unlock(); }
    }
}

Key Takeaways

ReentrantReadWriteLock maximizes read-heavy performance by splitting synchronization into shared read locks and exclusive write locks.
Enabling fairness (fair = true) prevents writer starvation by prioritizing waiting writer threads over newly arriving reader threads in the acquisition queue.
Lock downgrading (acquiring read lock while holding write lock, then releasing write lock) is fully supported, whereas lock upgrading is impossible and triggers deadlocks.

Full working implementation with execution trace available at https://javalld.com/learn/reader-writer

Stop Bloating Vector Indexes: Slicing Embeddings with Spring AI and Pgvector

Machine coding Master — Sun, 27 Sep 2026 08:38:38 +0000

Stop Bloating Vector Indexes: Slicing Embeddings with Spring AI and Pgvector

Your Postgres instance is quietly running out of RAM because you are indexing default 1536-dimensional vectors for chunks that require a fraction of that depth. Matryoshka Representation Learning (MRL) lets you safely prune up to 75% of those dimensions without sacrificing retrieval recall, slashing your pgvector index footprint overnight.

Why Most Developers Get This Wrong

Assuming embedding dimensions are immutable: Blindly persisting 1536d or 3072d vectors directly into pgvector and wondering why the HNSW graph spills out of shared_buffers directly to disk.
Truncating arbitrary embeddings: Slicing vectors generated by standard non-MRL models (like legacy Ada models), which completely breaks vector space geometry and destroys cosine similarity.
Over-engineering with client-side PCA: Adding complex dimensionality reduction pipelines in Java services instead of using models specifically pre-trained to nest semantic information in prefix sub-vectors.

The Right Way

Let MRL models pack the highest-variance features into the first $N$ dimensions, then slice the output directly through Spring AI during ingestion and query execution.

Deploy MRL-native models such as text-embedding-3-small or nomic-embed-text.
Enforce truncated dimensions at the application layer using Spring AI's native client configuration.
Re-index pgvector storage from vector(1536) down to vector(512) or vector(256), reducing index build times and query latencies exponentially.
Implement an optional two-stage retrieval: perform fast approximate nearest neighbors (ANN) on 256d vectors, then re-rank candidate documents if your domain requires razor-thin precision.

Heads up: if you want to see these patterns applied to real interview problems, javalld.com has full machine coding solutions with traces.

Show Me The Code

Configure your Spring AI bean to slice dimensions at the API boundary, keeping Postgres lean:

@Configuration
public class VectorStoreConfig {
    @Bean
    public EmbeddingModel embeddingModel(OpenAiConnectionProperties props) {
        var options = OpenAiEmbeddingOptions.builder()
            .model("text-embedding-3-small")
            .dimensions(512) // MRL slices 1536 -> 512 natively
            .build();
        return new OpenAiEmbeddingModel(new OpenAiApi(props.getApiKey()), MetadataMode.EMBED, options);
    }
}
// Postgres schema:
// ALTER TABLE vector_store ALTER COLUMN embedding TYPE vector(512);
// CREATE INDEX ON vector_store USING hnsw (embedding vector_cosine_ops);

Key Takeaways

70%+ RAM reduction: Moving from 1536 to 512 dimensions drops Postgres vector memory pressure by roughly 66% while retaining over 98% of retrieval recall.
Zero client-side math: Spring AI handles the dimension constraint natively through OpenAiEmbeddingOptions, offloading dimensionality management to the model provider.
HNSW stays in memory: Smaller vectors keep your graph indices inside Postgres shared_buffers, eliminating costly NVMe disk paging during similarity scans.