Spring Boot & Microservices

Tests whether you know Spring Boot is an opinionated, auto-configured layer on top of Spring, not a replacement for it.

Tests whether you know this one annotation is really @Configuration + @EnableAutoConfiguration + @ComponentScan bundled together.

Tests whether you know how to expose health, metrics, and diagnostic data for a production Spring Boot application.

Tests whether you know how to structure environment-specific configuration cleanly using @Profile and profile-specific property files.

Tests whether you actually understand what each pool setting controls, not just that HikariCP exists.

Tests whether you know to check for connection leaks, undersized pools, and long-running queries holding connections.

Tests whether you know HikariCP's leakDetectionThreshold setting and how to act on the warnings it logs.

Tests whether you know one bounds waiting for a pooled connection and the other bounds waiting for the database itself to respond.

Tests whether you know the counterintuitive rule that a smaller, correctly-sized pool often outperforms a large one.

Tests whether you know a slow downstream call while holding a pooled connection can exhaust the whole pool for every other request.

Tests whether you know constructor, setter, and field injection, and can explain the core DI concept itself.

Tests whether you know these are semantically distinct despite all being stereotypes of @Component under the hood.

Tests whether you know why constructor injection is the recommended default for immutability and testability.

Tests whether you can trace a bean from instantiation through initialization callbacks to destruction.

Tests whether you understand Spring's three-level cache trick for singletons, and why constructor injection can't use it.

Tests whether you understand the actual tradeoffs instead of defaulting to 'reactive is always better.'

Tests whether you know one thread blocks per request while the other multiplexes many requests over a few threads via callbacks.

Tests whether you know a fast producer can overwhelm a slow consumer without an explicit mechanism to signal capacity back upstream.

Tests whether you know a single blocking call can stall an entire event-loop thread serving many other requests.

Tests whether you know CPU-bound work and code with synchronized blocks don't benefit the way I/O-bound work does.

Tests whether you know the distinction between a zero-or-one-element stream and a multi-element async stream.

Tests whether you know when to substitute a fallback value versus swap in a whole fallback publisher versus simply retry.

Tests whether you know @RestController implicitly adds @ResponseBody to every handler method.

Tests whether you know how to control status codes, headers, and body together instead of always returning 200.

Tests whether you know how to centralize error handling instead of wrapping every controller method in try-catch.

Tests whether you know Pageable and Sort, and how to avoid returning an unbounded result set from an API.

Tests whether you know enable.idempotence alone only prevents duplicate writes at the broker, not end-to-end exactly-once.

Tests whether you know this is the classic dual-write problem, and that the Outbox Pattern is the real fix, not a retry loop.

Tests whether you know the message will be redelivered, which is exactly why consumer-side idempotency is non-negotiable.

Tests whether you know to check for GC pauses freezing poll(), slow downstream calls in the consumer, or an actual rebalance loop.

Tests whether you know a poorly chosen partition key (like a low-cardinality field) creates a hot partition.

Tests whether you know session timeouts, slow processing exceeding max.poll.interval.ms, and static membership all factor in.

Tests whether you know partition count is a hard ceiling on consumer parallelism within a group — the extra 7 sit idle.

Tests whether you know to replay from the DLT deliberately rather than just deleting and hoping the source retries.

Tests whether you know manual commit lets you commit only after successful processing, avoiding silent message loss.

Tests whether you know transactional.id and KafkaTransactionManager, and what read_committed means for downstream consumers.

Tests whether you know a slow batch that exceeds max.poll.interval.ms triggers a rebalance even though the consumer is still alive.

Tests whether you can reason through a real high-stakes production incident, not just recite the theory around lag.

Tests whether you can combine idempotent producers, Kafka transactions, and a transactional outbox into one coherent design.

Tests whether you know JPA is a specification and Hibernate is one implementation of it, among others.

Tests whether you know the basic annotations that map a Java class onto a database table.

Tests whether you know the extra JPA-specific and pagination/sorting capabilities JpaRepository adds on top.

Tests whether you know how Spring Data JPA generates SQL just from a method name's naming convention.

Tests whether you can correctly model and annotate all four core JPA relationship types.

Tests whether you know which side of a bidirectional relationship actually controls the foreign key column.

One of the most common Spring/JPA production bugs — tests whether you know how to spot and fix it with fetch joins or EntityGraph.

Tests whether you know why lazy loading is the safer default and what breaks when you get it wrong (LazyInitializationException).

Tests whether you know how Hibernate tracks an entity's lifecycle relative to the persistence context.

Tests whether you know the session-scoped cache is mandatory and always on, unlike the optional second-level cache.

Tests whether you know how to share cached entities across sessions and the staleness risk that comes with it.

Tests whether you know Hibernate auto-detects field changes on a managed entity and flushes UPDATE statements without an explicit save call.

Tests whether you know one returns null and the other a lazy proxy when the record doesn't exist.

Tests whether you know @Cacheable alone doesn't coalesce concurrent misses, and what actually does (locking, soft TTL).

Tests whether you know caching should degrade gracefully to the database, not become a hard dependency that takes down the app.

Tests whether you know local in-memory caches need a coordination mechanism (pub/sub or shared cache) to stay consistent across instances.

Tests whether you know the tradeoffs between allkeys-lru, volatile-lru, allkeys-lfu, and the noeviction default.

Tests whether you know the difference between a raw atomic SETNX-with-TTL lock and a library that handles renewal and edge cases for you.

Tests whether you know a second process can acquire the 'freed' lock while the first is still working, causing double-processing.

Tests whether you know batching commands avoids paying a network round trip for every single Redis call.

Tests whether you know one shards data across nodes for scale while the other provides high availability via failover for a single dataset.

Tests whether you know to proactively pre-populate hot keys instead of letting production traffic discover the cold cache.

Tests whether you know a Bloom Filter can cheaply reject requests for keys that provably don't exist, before they ever reach the DB.

Tests whether you know unbounded cache growth (no TTL, no max size) silently turns a cache into a memory leak.

Tests whether you know the basics of Spring's declarative transaction management and its annotation scope rules.

Tests whether you know how nested @Transactional calls decide whether to join, suspend, or start a new transaction.

Tests whether you know how READ_UNCOMMITTED through SERIALIZABLE trade off consistency against concurrency.

One of the most-asked Spring gotchas — tests whether you know self-invocation, private methods, and proxy limitations break it silently.

Tests whether you know how version-column-based conflict detection avoids holding a database lock for the whole transaction.

Tests whether you know a request passes through an ordered chain of filters before ever reaching your controller.

Tests whether you know how a stateless, signed token replaces server-side session storage for authentication.

Tests whether you know @PreAuthorize supports full SpEL expressions while @Secured only supports simple role checks.

Tests whether you know why CSRF matters for browser sessions but is usually irrelevant for stateless token-based APIs.

Tests whether you know the basics of Spring's caching abstraction layer over providers like EhCache or Redis.

Tests whether you know when to read from cache, remove from cache, or always update the cache regardless of a hit.

Tests whether you know how aspect-oriented programming pulls cross-cutting concerns like logging and security out of business logic.

Tests whether you know 2PC's blocking coordinator model doesn't scale and creates a single point of failure across services.

Tests whether you've thought past the happy path — what happens when the undo step doesn't work either.

Tests whether you can reason through a concrete Saga recovery scenario, not just define the pattern abstractly.

Tests whether you know the trick isn't stopping duplicates from arriving — it's making processing idempotent so duplicates are harmless.

Tests whether you know writing to a DB and publishing an event are two separate operations that can't be made atomic without help.

Tests whether you know CDC tails the database's own write-ahead log to publish outbox rows, instead of a fragile polling loop.

Tests whether you know to prune published rows and index the table correctly so it doesn't become its own bottleneck.

Tests whether you can translate a technical consistency model into a concrete business-facing tradeoff.

Tests whether you know this needs dedicated integration environments and event-assertion tooling, not just unit tests per service.

Tests whether you know Outbox solves reliable event publishing while Saga solves multi-step business transaction coordination — they're often used together.

Tests whether you know tracking processed message IDs in a dedicated table is the consumer-side mirror of the Outbox Pattern.

Tests whether you can explain the tradeoffs, not just the buzzword — independent deployability versus operational simplicity.

Tests whether you understand why sharing one database across services quietly turns microservices back into a distributed monolith.

Tests whether you know how to incrementally carve services out of a monolith without a risky big-bang rewrite.

Tests whether you understand why hardcoded service IPs break down once instances scale and move dynamically.

Tests whether you know the registration and heartbeat mechanism behind Netflix Eureka.

Tests whether you know who's responsible for load-balancing the lookup result — the calling client or an intermediary.

Tests whether you know the gateway's role in routing, auth, rate limiting, and shielding internal services from clients.

Tests whether you know how to configure a request-rate-limiter filter backed by Redis to throttle abusive clients.

Tests whether you know how to centralize configuration across many microservices instead of duplicating property files.

Tests whether you know how to pick up new config values live without redeploying a running service.

Tests whether you know low CPU with high failure at scale usually points to thread pool or connection pool saturation, not compute.

Tests whether you know averages mask tail latency, and that a small fraction of very slow requests is often the actual production issue.

Tests whether you know synchronized retries without jitter can pile onto an already-struggling service and push it further down.

Tests whether you know these four resilience patterns solve different failure modes and are usually layered together, not chosen one at a time.

Tests whether you've thought through the race condition of two identical requests landing at nearly the same instant.

Tests whether you know optimistic locking (a version check) catches this cleanly without holding a lock the whole time.

Tests whether you can pick correctly between optimistic locking, pessimistic locking, or an atomic decrement for this exact scenario.

Tests whether you know to stream and process the file line by line instead of loading it entirely into memory first.

Tests whether you know a propagated correlation ID plus distributed tracing is what makes this actually possible.

Tests whether you know timeout budgets must cascade correctly — a downstream timeout longer than your own SLA guarantees you'll breach it.

Tests whether you know the practical implications each approach has for clients, caching, and backward compatibility.

Tests whether you know how a declarative HTTP client interface replaces manually built RestTemplate calls.

Tests whether you know WebClient supports non-blocking reactive calls while RestTemplate is fundamentally blocking (and now deprecated).

Tests whether you know how a circuit breaker stops hammering a failing downstream service and how it decides to retry.

Tests whether you can actually wire up the annotation-based Resilience4j circuit breaker with a fallback method.

Tests whether you know how isolating resource pools per dependency stops one slow service from starving all the others.

Tests whether you know the log-based streaming model versus traditional message-queue broker model, and when each fits.

Tests whether you know Kafka's core vocabulary and how partitions enable parallel consumption within a consumer group.

Tests whether you know how a trace ID follows a request across service boundaries to make debugging possible at all.

Tests whether you know both sides of a connection verify each other's certificate, not just the client verifying the server.

Tests whether you know how to maintain consistency across services without a distributed transaction, and the two coordination styles.

Tests whether you know why separating the write model from the read model can simplify a complex domain.

Tests whether you know how storing every state-changing event (instead of just current state) enables replay and audit.

Tests whether you know why you can't have Consistency, Availability, and Partition tolerance all at once, and what tradeoff you'd pick.

Tests whether you can spot an Open/Closed Principle violation in real code and know Strategy pattern is the standard fix.

Tests whether you know SRP is about reasons to change, not method count — a single method can still mix multiple concerns.

Tests whether you know abstracting for change that will never actually happen just adds indirection with no payoff.

Tests whether you know this is a Liskov Substitution violation even without a compile error — the contract broke silently.

Tests whether you know a bloated interface forces implementers to depend on methods they don't use, and how to migrate safely.

Tests whether you know DI is a mechanism while DIP is a design principle, and injecting a concrete class still violates DIP.

Tests whether you can map object-oriented design principles onto architectural decisions about service decomposition.

Tests whether you have a practical, prioritized approach to untangling a real legacy God class, not just theory.

Tests whether you know to check kubectl describe, previous container logs, OOMKilled status, and probe configuration.

Tests whether you know a common pitfall: using the same health endpoint for both can cause unnecessary pod restarts.

Tests whether you know Kubernetes' exponential backoff behavior for repeatedly-crashing containers and how to find the root cause fast.

Tests whether you know it prevents voluntary disruptions (like node drains) from taking down too many replicas at once.

Tests whether you know server.shutdown=graceful, a SIGTERM handler, and a preStop hook all need to work together.

Tests whether you know client-side connection reuse or a misbehaving load-balancing algorithm can defeat even distribution.

Tests whether you know a @Scheduled job needs a distributed lock (or ShedLock) to run exactly once across a clustered deployment.

Tests whether you know to check DB connectivity latency, DNS resolution, and autoconfiguration scanning under production networking.

Tests whether you know exceeding a CPU limit throttles the pod while exceeding a memory limit gets it OOMKilled outright.

Tests whether you know only certain request types (non-simple methods, custom headers) force the browser to preflight first.

Tests whether you know Access-Control-Allow-Origin, -Credentials, and -Methods and how to configure them without accidentally opening your API to everyone.

Tests whether you know inserts during scrolling shift offsets and cause skipped or duplicated rows, which cursors avoid entirely.

Tests whether you know to base64-encode the actual sort key values instead of exposing raw IDs or offsets directly.

Tests whether you know Flyway's plain-SQL-first philosophy versus Liquibase's changelog-based, database-agnostic approach.

Tests whether you know to add new columns first, deploy dual-compatible code, migrate data, and only remove old columns in a later release.

Tests whether you know old and new pod versions run against the same schema simultaneously during a rollout, so migrations must be backward-compatible.

Tests whether you know gRPC's binary Protobuf format and HTTP/2 multiplexing pay off specifically for low-latency internal service calls.

Tests whether you know when a simple request-response isn't enough and one side (or both) needs to stream data continuously.

Tests whether you know SSE fits one-way server-to-client streaming, while WebSocket is needed for genuine bidirectional communication.

Tests whether you know a client's SSE connection is pinned to one server instance, so events must be fanned out to whichever instance holds that connection.

Tests whether you know structured fields let log aggregation tools query and filter logs instead of grepping through text.

Tests whether you know how to thread a correlation ID through every log statement without passing it as a parameter everywhere.

Tests whether you can name logs, metrics, and traces and connect each to a concrete Java tool (structured logs, Micrometer, OpenTelemetry).