V5.2 — 261 Question–Answer theo đúng thứ tự học xen kẽ

TTS 002 · A: A requirement describes what users need. A business rule describes the conditions the system must follow. For example, users can book rooms, but they cannot book an unavailable room.

TTS 004 · A: First, the API receives the booking request. Then the service checks dates and availability. Finally, the database stores the booking, and the API returns the result.

TTS 006 · A: A functional requirement describes what the system must do. For example, customers need to create and cancel bookings.

TTS 008 · A: An invariant is a rule that must remain true after every valid operation. For example, one room must not be allocated to two confirmed bookings for the same night.

TTS 010 · A: Staff approval changes the booking workflow. I need to know whether a booking stays pending and whether it holds a room before approval. This affects states, availability, and tests.

TTS 012 · A: I would add a cancellation action and define who can cancel and when. The service should validate the booking state and update availability according to the agreed policy.

TTS 014 · A: I would test invalid dates, unavailable rooms, and successful bookings. I would also test concurrent requests, permissions, and the approval workflow if approval is required.

TTS 016 · A: It requires a step-by-step explanation, not just a definition. I would explain how an index helps find matching rows, and then mention the extra storage and write cost.

TTS 018 · A: Least means the smallest amount or the lowest effectiveness. So I must choose the action that is least effective at preventing duplicate bookings, not the best action.

TTS 020 · A: A requirement tells us what the system needs to do. An assumption is something we believe is true but still need to confirm. I would check important assumptions with the customer.

TTS 022 · A: It asks me to find the option that does not satisfy the stated condition. I would read all the options before choosing an answer.

TTS 024 · A: I would say, Could you repeat that technical term, please? If I still do not understand, I would ask the interviewer to explain it in another way.

TTS 026 · A: I would ask what matters most, such as response time, cost, or consistency. The best solution depends on these constraints, so I would not choose one before clarifying them.

TTS 028 · A: I would explain what I know and make my uncertainty clear. Then I would describe how I would verify the missing detail. I would not claim experience I do not have.

TTS 030 · A: I would create Student, Course, and Enrollment entities. Enrollment connects a student to a course and stores its status. The main rule is that active enrollments must not exceed the course capacity.

TTS 032 · A: Usually, I would prevent duplicate active enrollments for the same student and course. I could enforce this with an appropriate database constraint and test two concurrent enrollment requests.

TTS 034 · A: An entity represents important domain data and may contain domain behavior. A service coordinates a use case or business operation. For example, a BookingService creates a Booking while enforcing its rules.

TTS 036 · A: I would protect the last seat inside the database using a suitable lock or atomic update. Two requests must not both reserve the same seat. I would verify this with a concurrent test.

TTS 038 · A: I would log in as a normal employee and call the approval API. I would expect a forbidden response and no status change. Then I would repeat the test with an authorized team lead.

TTS 040 · A: I would define a drop action and change the enrollment status. If the course uses reserved seats, dropping should release one. I would test that the available capacity is updated correctly.

TTS 042 · A: I would define states such as DRAFT, SUBMITTED, APPROVED, and REJECTED. Then I would list allowed transitions and who can perform them. I would test invalid transitions and self-approval.

TTS 044 · A: The controller receives the HTTP request, validates its structure, and returns a response. The service applies registration rules, hashes the password, and coordinates saving the user and verification token.

TTS 046 · A: Different rules for uppercase letters or spaces can create duplicate accounts or unexpected login behavior. I would define normalization and comparison clearly, then enforce the same rule in the database.

TTS 048 · A: For password verification, I would store a salted, slow password hash rather than a recoverable password. The server can verify a candidate password without storing plaintext. A suitable password-hashing algorithm also makes offline guessing harder.

TTS 050 · A: Validation checks that the input satisfies format and business constraints. Authorization checks whether a caller may perform an action. Public registration may not require an existing account, but later account changes require access checks.

TTS 052 · A: I would normalize the email according to a clear policy and enforce uniqueness in the database. A pre-check improves the message, but the unique constraint handles concurrent inserts.

TTS 054 · A: The user may already be saved, even if the email could not be delivered. I would record the delivery task and retry it safely. A database rollback cannot automatically undo an external email failure.

TTS 056 · A: I would store a hash of a strong random token and give it an expiration time. The token should be single-use. I would test expired, reused, and concurrent token requests.

TTS 058 · A: I would save the user and a durable email-delivery task in one local transaction. A worker can send the email and retry failures. I would also make delivery processing safe when messages are duplicated.

TTS 060 · A: A primary key uniquely identifies each row in a table. Its value must not be null, and the database enforces uniqueness.

TTS 062 · A: A foreign key links a row to a key in another table. It helps the database enforce referential integrity between related records.

TTS 064 · A: An INNER JOIN returns only customers with matching bookings. A LEFT JOIN keeps every customer, even when no booking exists. The booking fields are null for customers without a match.

TTS 066 · A: WHERE filters rows before grouping. HAVING filters groups after aggregation. For example, I would use HAVING to keep customers whose total spending exceeds a threshold.

TTS 068 · A: COUNT(*) counts rows, including rows with null values. COUNT(column) counts only rows where that column is not null.

TTS 070 · A: UNION removes duplicate rows from the combined result. UNION ALL keeps duplicates and usually avoids the cost of removing them.

TTS 072 · A: An index is a data structure that helps the database find matching rows efficiently. It can improve reads, but it uses storage and requires maintenance during writes.

TTS 074 · A: The database may need to update one or more indexes when a row changes. That extra work can increase the cost of writes. I would add indexes based on measured query needs.

TTS 076 · A: Not automatically. If the status column has only a few common values, the index may not help much. I would inspect the execution plan and real query workload first.

TTS 078 · A: I would inspect the execution plan and measure how many rows the query reads. Then I would check selectivity, join conditions, sorting, and whether the index is actually used.

TTS 080 · A: Atomicity means a transaction succeeds or fails as one unit. Isolation describes how concurrent transactions see and affect each other. Both matter, but they solve different problems.

TTS 082 · A: ACID stands for atomicity, consistency, isolation, and durability. These properties describe important guarantees and boundaries of database transactions.

TTS 084 · A: A dirty read sees changes that another transaction has not committed. A non-repeatable read happens when the same row is read twice and its committed value changes between reads.

TTS 086 · A: A phantom read happens when repeating a query with the same condition returns a different set of rows because another transaction changed matching rows. The available protections depend on the database and isolation level.

TTS 088 · A: A transaction gives atomic behavior, but two transactions can still pass the same availability check. I would use suitable locking, an atomic update, or a database constraint to protect inventory.

TTS 090 · A: Optimistic locking detects conflicts when updating, often by checking a version value. Pessimistic locking locks data before a conflicting operation can proceed. I would choose based on contention and the cost of retries.

TTS 092 · A: I would run two requests that read and update the same record at nearly the same time. Then I would compare the final value with the expected result and verify that no update was lost.

TTS 094 · A: First, the browser resolves the domain name and establishes a secure connection. Then it sends an HTTPS request. The backend processes it and returns an HTTP response.

TTS 096 · A: HTTP 401 means the request does not have valid authentication. HTTP 403 means the server understands the request but refuses access, even when the user may be authenticated.

TTS 098 · A: Not blindly. A timeout does not prove that the operation failed. I would retry only with a safe strategy, such as an idempotency key, and check the booking status.

TTS 100 · A: GET is intended to retrieve a representation without causing requested business side effects. POST submits data for processing and can create or change server state. A POST is not automatically safe to retry.

TTS 102 · A: PUT generally replaces the target resource representation according to the API contract. PATCH applies a partial change. I would check the API's documented semantics instead of assuming every update is idempotent.

TTS 104 · A: 200 means the request succeeded and usually includes a response representation. 201 indicates a resource was created. 204 means the request succeeded without response content.

TTS 106 · A: 400 means the request is invalid, and 404 means the resource was not found. 409 indicates a conflict with the current resource state. 500 indicates an unexpected server-side error.

TTS 108 · A: A timeout means the expected operation or response did not complete within the allowed time. A connection refusal means the connection attempt was actively rejected. Neither result alone proves whether an earlier request committed.

TTS 110 · A: A client can reuse the same key when retrying one logical operation. The server can recognize the request and return its earlier result without repeating the side effect. This requires a reliable server-side implementation.

TTS 112 · A: The server may have committed the booking even though the client saw a timeout. I would use the same idempotency key or operation ID to retrieve the earlier result and avoid duplicates.

TTS 114 · A: I would return a stable operation ID and expose a status endpoint. The client could check whether the operation is pending, successful, failed, or still unknown.

TTS 116 · A: A process has its own address space and resources. Threads within one process share heap objects, but each thread has its own execution stack. This makes communication easier but creates shared-state risks.

TTS 118 · A: The increment is a read, an addition, and a write. Two threads may read the same old value and write the same new value. This can lose one increment.

TTS 120 · A: Synchronized protects threads sharing the same lock inside one application instance. Two backend instances do not share that Java lock. I would protect shared database state at the database level.

TTS 122 · A: No. Volatile helps with visibility, but count plus plus is still a compound operation. I would use an atomic counter or proper synchronization for an in-memory value.

TTS 124 · A: A race condition happens when the result depends on the timing of concurrent operations. For example, two threads may read the same stock value and both attempt to sell the last item.

TTS 126 · A: A deadlock happens when operations wait for resources held by one another and none can progress. I would reduce inconsistent lock ordering and use suitable timeouts or deadlock detection.

TTS 128 · A: Concurrency means several tasks make progress during overlapping periods. Parallelism means tasks execute at the same time on different processing resources.

TTS 130 · A: Each Java thread has its own execution stack for frames and local execution state. Objects are generally allocated on the heap, which threads may share. Shared mutable objects need careful coordination.

TTS 132 · A: Both can protect critical sections inside one JVM. ReentrantLock offers features such as timed lock attempts and interruptible lock acquisition. Neither automatically coordinates separate backend instances.

TTS 134 · A: An application can keep references to objects that are no longer needed. For example, an unbounded cache or a static collection may keep growing. Garbage collection cannot reclaim objects that remain reachable.

TTS 136 · A: I would choose an atomic SQL update when multiple application instances change the same database record. A local Java lock cannot coordinate all those instances.

TTS 138 · A: I would model Customer, Room, Booking, and nightly inventory. A new booking can start in PENDING and move to CONFIRMED after staff approval. I would validate permissions and state transitions.

TTS 140 · A: It depends on the business policy. Holding inventory protects pending requests but can block other customers. Not holding it improves availability but means approval may fail later.

TTS 142 · A: A state transition changes a booking from one allowed state to another. For example, staff approval may move PENDING to CONFIRMED. I would reject transitions that violate the agreed business policy.

TTS 144 · A: I would protect room-night allocation in the database, not just with an application pre-check. A constraint or suitable transaction and lock should prevent overlapping allocations. I would test concurrent requests.

TTS 146 · A: I would clarify the cancellation deadline and refund policy. Then I would allow valid state transitions and release reserved nights when the business rules require it.

TTS 148 · A: I would keep allocation for all required nights in one suitable database transaction when possible. If any night fails, I would roll back the local allocation and return a conflict.

TTS 150 · A: I would define precisely which bookings reserve inventory and which dates are included. Then I would use a database allocation model and suitable constraints or locking. I would test overlapping and adjacent date ranges concurrently.

TTS 152 · A: I would treat the operation as inconsistent until its status is reconciled. A local transaction cannot undo the provider's confirmation automatically. I would record operation identifiers and use an agreed compensation or support workflow.

TTS 154 · A: A unit test checks a small piece of logic in isolation. An integration test checks how real components work together. For example, it can verify a service using a real test database.

TTS 156 · A: No. High coverage means many lines or branches were executed. It does not prove that the assertions are correct or that all important edge cases were tested.

TTS 158 · A: Authentication checks who the user is. Authorization checks what that user can do. For example, a customer may be logged in but still cannot approve a booking.

TTS 160 · A: Mocking replaces a dependency with a controlled test double. It can verify interactions or simulate failures. I would still use integration tests to check real database behavior.

TTS 162 · A: Authentication establishes who the caller is. Role-based authorization uses roles or permissions to decide what actions that caller may perform. Object ownership can require extra checks beyond the role.

TTS 164 · A: Symmetric encryption uses a shared secret key for encryption and decryption. Asymmetric encryption uses a related public and private key pair. The right choice depends on the protocol and security goal.

TTS 166 · A: A virtual machine runs its own guest operating system on virtualized hardware. A container normally shares the host kernel while isolating application processes. Containers are often lighter, but isolation and security still need configuration.

TTS 168 · A: Big O describes how an algorithm’s resource usage grows as the input size increases. I use it to compare growth rates, such as O(n) and O(n²), while stating the assumptions.

TTS 170 · A: A stack uses last in, first out order. A queue uses first in, first out order. For example, DFS can use a stack, while BFS commonly uses a queue.

TTS 172 · A: Breadth-first search explores nodes level by level, commonly using a queue. Depth-first search explores a path deeply before backtracking, using a stack or recursion. With an adjacency list, both run in O(V + E) time.

TTS 174 · A: Quick Sort can create very unbalanced partitions, leading to quadratic work. Merge Sort repeatedly splits the input and merges sorted halves, giving O(n log n) time in the usual implementation. Their memory trade-offs are different.

TTS 176 · A: I would use parameterized queries or safely bound ORM parameters, not build SQL by concatenating untrusted input. I would also validate inputs and limit database permissions. Validation alone is not a replacement for parameter binding.

TTS 178 · A: I would test the approval API with a staff account and expect success. Then I would use a customer account and expect a forbidden response with no booking state change.

TTS 180 · A: No. I would first measure latency and check logs, slow SQL queries, and resource usage. More servers will not necessarily fix a slow database query.

TTS 182 · A: Binary search repeatedly halves a sorted search range. Its time complexity is O(log n), and an iterative implementation can use O(1) extra space. The input must satisfy the sorted-order assumption.

TTS 184 · A: No. Static means a field or method belongs to the class rather than one object. Multiple threads can still access a shared static field and cause a race condition.

TTS 186 · A: Static means a member belongs to a class rather than a particular object. A static mutable field can still be accessed by multiple threads. It does not guarantee atomic or thread-safe updates.

TTS 188 · A: Static methods are hidden, not overridden polymorphically. The method selected depends on the compile-time reference type, not the runtime object type. I prefer calling static methods through the class name.

TTS 190 · A: Final restricts reassignment, overriding, or inheritance depending on where it is used. Finally is a block that normally runs when a try statement completes. Finalize is an obsolete cleanup mechanism that should not be relied on.

TTS 192 · A: For object references, double equals compares whether they point to the same object. The equals method can compare logical values. For example, two different String objects may have equal text.

TTS 194 · A: A mutable key may change its hash code after insertion. Then HashMap may search the wrong bucket and fail to find the key. I would prefer immutable keys.

TTS 196 · A: Java is always pass-by-value. When I pass an object, the method receives a copy of the reference value. It can change the object, but reassigning the parameter does not replace the caller’s reference.

TTS 198 · A: HashMap uses hash codes to locate candidate entries and equals to identify a matching key. Equal keys must have equal hash codes. Changing a key's equality-related fields after insertion can break lookup.

TTS 200 · A: Java passes a copy of the reference value to the method. Reassigning that local copy does not change the caller's variable. Mutating the referenced object can still be visible to the caller.

TTS 202 · A: String is immutable. StringBuilder is a mutable text builder without synchronized methods. StringBuffer synchronizes many operations, but that does not automatically make a multi-step workflow atomic.

TTS 204 · A: A thread's stack stores call frames and execution state. The heap typically stores objects shared by reference across code and threads. The precise runtime optimizations are managed by the JVM.

TTS 206 · A: Equals determines whether two objects are logically equal according to a class's implementation. If two objects are equal, their hash codes must match. The reverse is not guaranteed because hash collisions are possible.

TTS 208 · A: An interface defines a contract that classes can implement. An abstract class can provide shared state, constructors, and common implementation. I would choose based on the relationship and design needs.

TTS 210 · A: Overloading uses the same method name with different parameter lists, and selection is based mainly on compile-time types. Overriding provides a new implementation of an inherited instance method, selected by runtime dispatch.

TTS 212 · A: Encapsulation groups data with behavior and controls access to internal state. For example, a Booking object can expose an approve method instead of allowing arbitrary status changes.

TTS 214 · A: Inheritance models an is-a relationship between types. Composition builds behavior by combining objects. I prefer composition when I need to change policies without creating a fragile class hierarchy.

TTS 216 · A: Polymorphism lets code use a common type while different implementations provide different behavior. For example, a CheckoutService can call a DiscountPolicy interface without knowing the specific discount algorithm.

TTS 218 · A: Abstraction exposes the important contract while hiding implementation details. For example, a PaymentGateway interface can describe a charge operation without exposing the provider's HTTP calls.

TTS 220 · A: I would use an interface to define a contract that different classes can implement. I would use an abstract class when related classes need shared state or common implementation.

TTS 222 · A: No. Garbage collection manages reclaimable Java objects, not timely release of every external resource. I would close connections and streams appropriately, often with try-with-resources or a managed framework.

TTS 224 · A: Checked exceptions generally must be caught or declared by the compiler. Unchecked exceptions are RuntimeException types and their subclasses. I choose handling based on whether callers can meaningfully recover.

TTS 226 · A: List is an ordered collection that can contain duplicates. Set stores unique elements according to its equality rules. Map associates keys with values and requires unique keys.

TTS 228 · A: HashMap is not safe for unsynchronized concurrent modifications. ConcurrentHashMap supports concurrent access with its own concurrency guarantees. For compound operations, I would still choose the appropriate atomic map method.

TTS 230 · A: HashSet uses hashing and does not guarantee sorted iteration order. TreeSet maintains a sorted order using natural ordering or a comparator. Their performance and element requirements differ.

TTS 232 · A: Generics let me express type constraints, such as List, at compile time. They improve type safety and reduce casts. Java implements most generic type checks through type erasure.

TTS 234 · A: Comparable defines an object's natural ordering. Comparator defines an external ordering strategy. I can use different comparators to sort the same objects in different ways.

TTS 236 · A: Map transforms each element into another value. Filter keeps only elements that satisfy a predicate. Neither operation changes the original collection by itself.

TTS 238 · A: I usually choose ArrayList for indexed access and efficient iteration. LinkedList may help with some insertions when I already hold the node position, but searching and memory overhead matter. I would measure before switching.

TTS 240 · A: Optional can make the possible absence of a result explicit in a return type. For example, a repository lookup may return Optional. I would not automatically use Optional for every field or parameter.

TTS 242 · A: Both requests may read the same old value and overwrite each other's update. This is a lost-update race. I would use an atomic operation or suitable synchronization for in-memory state.

TTS 244 · A: Spring is a framework and ecosystem for building applications. Spring Boot provides conventions, auto-configuration, and starter dependencies to simplify setup and deployment.

TTS 246 · A: A bean is an object managed by the Spring container. With constructor injection, Spring supplies the required dependencies when the object is created. It makes required dependencies explicit.

TTS 248 · A: All three can identify components for Spring to manage. Service communicates a business-layer role, while Repository communicates a persistence-layer role and can enable persistence exception translation. Component is a general stereotype.

TTS 250 · A: Inversion of control means the framework manages object creation and wiring rather than application code creating every dependency. Dependency injection is a common way to implement it.

TTS 252 · A: Constructor injection exposes required dependencies and makes them easier to provide in tests. It also supports immutable dependency fields. I would avoid injecting a long list of unrelated services into one class.

TTS 254 · A: Auto-configuration registers useful beans based on the dependencies, properties, and other beans available. It reduces manual configuration while still allowing explicit customization.

TTS 256 · A: Injection by type may be ambiguous when several beans qualify. I can use a qualifier or select a primary bean to make the dependency clear.

TTS 258 · A: The controller handles the HTTP request and input validation. The service applies business rules. The repository reads and writes data. Spring manages these components and injects their dependencies.

TTS 260 · A: No. Validation annotations do not reliably enforce uniqueness across concurrent requests. I would use a database unique constraint and handle its violation.

TTS 262 · A: No. Validation can check request data, but it cannot reliably protect against a race between two inserts. I would enforce email uniqueness in the database and handle constraint violations.

TTS 264 · A: RestController combines controller behavior with response-body serialization for request handlers. Its methods commonly return objects that Spring converts to JSON according to the configured converters.

TTS 266 · A: RequestParam reads values from request parameters. PathVariable binds values from the URL path. RequestBody reads and converts the HTTP request body.

TTS 268 · A: Spring can validate a request DTO when it is bound to a validated method parameter. I would define constraints such as not blank and positive values. Business invariants still need service and database protection.

TTS 270 · A: I would authenticate the caller and then enforce the required permission or resource ownership. I would also validate inputs and test both authorized and forbidden requests. Authentication alone is not enough.

TTS 272 · A: Flush sends pending SQL changes to the database, but the transaction may still be open. Commit makes the transaction complete and its changes durable according to the database guarantees.

TTS 274 · A: An N plus one problem happens when one query loads a list and extra queries load related data for each item. I would inspect SQL logs and use a suitable fetch plan or projection.

TTS 276 · A: JPA, now under Jakarta Persistence, defines an API and specification for persistence. Hibernate is an implementation of that specification and provides additional features.

TTS 278 · A: The persistence provider can detect changes to a managed entity and write them during flush. If the transaction commits successfully, those database changes can persist without an explicit save call for every field change.

TTS 280 · A: Lazy loading fetches related data when the application accesses it. It can fail when the required persistence context is no longer available. I would plan the fetch strategy for each use case.

TTS 282 · A: An entity represents a persistence-managed domain object. A DTO is shaped for transferring data between boundaries. I usually avoid returning entities directly when it could expose fields or trigger unwanted lazy loading.

TTS 284 · A: The persistence context tracks managed entities and their identities within a unit of work. It can reuse already managed objects and detect changes before a flush.

TTS 286 · A: Persist makes a new entity managed so it can be inserted. Merge copies state from a detached entity into a managed instance and returns that managed instance. I would not assume merge reattaches the original object.

TTS 288 · A: Lazy fetching defers loading an association until needed. Eager fetching requires the association to be available, but it does not promise one SQL query. I would choose fetch plans based on the use case.

TTS 290 · A: I would use them when one query needs selected related entities and extra lazy loads are costly. I would be careful with paging queries that join large collections. A DTO projection may be simpler for list views.

TTS 292 · A: No. Transactional does not automatically protect every check-then-insert race. I would choose a suitable isolation level, lock, constraint, or atomic update and test concurrent requests.

TTS 294 · A: By default, Spring rolls back for RuntimeException and Error. Checked exceptions do not trigger rollback by default. I can configure rollback rules when business behavior requires it.

TTS 296 · A: No. Transaction boundaries alone do not prevent every read-check-write race. I would use appropriate database protection, such as an atomic update, lock, or constraint, and verify the outcome with a concurrent test.

TTS 298 · A: In common proxy-based Spring transaction management, a call within the same object bypasses the transactional proxy. The expected transaction advice may not run. I would restructure the boundary or use the appropriate configuration.

TTS 300 · A: N plus one happens when one query loads a list and additional queries fetch related data item by item. I would inspect SQL logs, query counts, and endpoint performance. Then I would choose a projection or an appropriate fetch strategy.

TTS 302 · A: I would use integration tests with a real test database for transaction behavior. I would simulate external API success, timeout, and duplicate responses. Then I would verify both database state and recovery behavior.

TTS 304 · A: Two booking requests can check the same available room before either saves a booking. Both may then return success. The bug is a read-check-write race that can cause overbooking.

TTS 306 · A: I could use an atomic conditional inventory update and check the affected row count. Another option is a database constraint or row lock with a suitable transaction. The choice depends on the schema.

TTS 308 · A: A transaction can make the local database changes atomic. It does not automatically make a separate external API call atomic or prevent every concurrency race without the right database protection.

TTS 310 · A: Two requests read the last available item before either update becomes visible. Both may believe they can reserve it. I would move the critical check and update into a protected database operation and test two concurrent requests.

TTS 312 · A: It should verify that the business invariant still holds in stored data. For one available room-night, at most one conflicting allocation should succeed. I would also check the returned statuses and any retry records.

TTS 314 · A: Two requests were able to reserve the same inventory because the availability check was not protected. I would enforce the rule in the database and run a concurrent test to confirm that only one request succeeds.

TTS 316 · A: If the system stores operation IDs and their results, it should return the original result instead of repeating the action. The behavior must be supported by a persistent idempotency mechanism.

TTS 318 · A: V-Market is a Java and Spring Boot commerce project with a product catalog, guest checkout, and CSV imports. Its main backend challenges are keeping stock correct and handling repeated checkout requests safely. The project does not claim real payment gateway integration.

TTS 320 · A: The browser sends a request through the Next.js backend-for-frontend to the Java API. Inside a database transaction, the service checks the operation key, locks stock rows, and validates the current price and quantity. It saves the order, inventory changes, movements, and audit together before returning the result.

TTS 322 · A: The first checkout locks the relevant stock row and may purchase twenty items. The second checkout waits and then reads the updated stock of seven. It must reject a request for twenty items, so the database never commits negative stock in this case.

TTS 324 · A: The operation-key lock prevents the same checkout operation from creating another order. Stock locks protect inventory when different operations compete for the same products. They solve different concurrency problems.

TTS 326 · A: The backend compares the guest scope, operation key, and request fingerprint. The same operation and payload can return the existing order during the replay window. Reusing the key with different quantities or customer data causes a conflict.

TTS 328 · A: No. A timeout does not prove the order was not committed. The client keeps the operation key and guest capability, and uses the recovery endpoint to check the result. It should not start a new operation blindly.

TTS 330 · A: Redis caches catalog metadata, not the authoritative stock count. The displayed availability is a snapshot, and checkout checks the database again under a lock. Cache freshness may affect displayed metadata, but cached availability is not trusted to commit an order.

TTS 332 · A: The order, order items, stock changes, inventory movements, and audit are written in one transaction. A rollback prevents those related database changes from being committed only partially. This does not mean external payment or delivery operations are covered by the transaction.

TTS 334 · A: The repository describes Testcontainers integration tests for overselling, simultaneous duplicates, and rejected key reuse. These tests check order counts, inventory changes, and database records, not just HTTP responses. They do not prove production reliability or that I personally ran the tests.

TTS 336 · A: It accepts UTF-8 and CP932 or Windows-31J with strict decoding. It checks the file structure, headers, columns, SKU values, and row data. Structural errors may reject the file, while invalid business rows can be stored for review.

TTS 338 · A: Unversioned legacy feeds can update metadata but not authoritative stock. A versioned stock snapshot must match the current stock version after the database lock is acquired. This prevents an old snapshot from silently overwriting a newer inventory state.

TTS 340 · A: V-Core is a Kanban collaboration project using Java, Spring Boot, PostgreSQL, and a React frontend. Its backend manages workspace permissions and concurrent task changes. A key rule is that moving tasks must not exceed a column's work-in-progress limit.

TTS 342 · A: The client sends the target column, the task version, and an idempotency key through a BFF. The service checks access, locks the target column, and validates the task version and WIP limit inside a transaction. It then saves the task change, activity, outbox record, and idempotency result.

TTS 344 · A: The column lock protects the shared WIP limit across different tasks. The task version prevents a stale update to one task. Two different tasks have different versions, so version checking alone cannot protect the column's capacity.

TTS 346 · A: Both operations need the target column lock before checking occupancy. One move fills the final slot and commits. The waiting request checks occupancy again and is rejected if the column is now full.

TTS 348 · A: The backend stores an idempotency key and a request hash scoped to the workspace. A matching retry can receive the saved response without applying the move again. Reusing the key with different content causes a conflict.

TTS 350 · A: The task change, activity record, outbox entry, and idempotency result are committed together. If the transaction rolls back, those database changes roll back together. The transaction does not guarantee that an SSE notification reaches every browser.

TTS 352 · A: The service checks the current session and workspace membership or role in PostgreSQL. It also scopes task queries to the requested workspace and project. A trusted BFF secret is not the same as user authorization, and a public viewer cannot perform writes.

TTS 354 · A: The repository includes an integration test that starts two competing moves for one remaining slot. The test checks both the responses and the final number of tasks in the column. I would explain the test from the code and avoid claiming that I personally ran it unless I did.

TTS 356 · A: SSE tells the user interface that workspace data may have changed. The interface then fetches current data from the database-backed API. The current feed can lose notifications, so SSE is a refresh hint, not a durable exactly-once event stream.

TTS 358 · A: The backend rechecks the original session, account, and workspace membership before events or heartbeats. If access cannot be verified, the stream is closed. This does not undo events already sent or promise instantaneous revocation at every moment.

TTS 360 · A: No. The current implementation locks the column and checks its version and occupancy. It rejects a new limit that is below the number of existing tasks. It does not automatically delete or move tasks to satisfy the limit.

TTS 362 · A: For an MVP, I would build one Spring Boot backend with a relational database. The service handles booking rules, and the database stores bookings and inventory. I would add monitoring and test failures before adding more components.

TTS 364 · A: I would consider Redis if repeated reads put too much load on the database. But final room allocation must not trust a possibly stale cache. The database should enforce the inventory rule.

TTS 366 · A: A load balancer distributes incoming requests across available backend instances. It can improve availability and capacity, but the instances must handle shared state correctly.

TTS 368 · A: Eventual consistency allows replicas or components to temporarily disagree. If updates stop and the system converges as designed, they eventually reach consistent state. I would clarify whether that delay is acceptable for the business rule.

TTS 370 · A: A modular monolith is easier to develop, test, and deploy for a small product. It avoids early distributed-system complexity. The trade-off is less independent scaling and deployment.

TTS 372 · A: I would set appropriate timeouts and identify whether the operation is safe to retry. I would track uncertain results and use a fallback or reconciliation workflow when the provider is unavailable.

TTS 374 · A: I would compare latency, error rate, and throughput before and after scaling under similar load. I would also check database load and costs to make sure the change actually helped.

TTS 376 · A: I would look for an idempotency contract and a way to check the original operation status. If I cannot confirm that repeating the request is safe, I would not retry it blindly.

TTS 378 · A: I would not assume the order failed. First, I would find the request ID and compare application logs with database records. Then I would check whether the order committed before the gateway timed out.

TTS 380 · A: I would reproduce the import with a small dataset and inspect duplicate records, request IDs, and retry behavior. Then I would identify the root cause and consider a stable external ID or database constraint.

TTS 382 · A: That could be a retry, duplicate log entry, or another processing issue. I would compare timestamps, handlers, and database effects before concluding that the business action ran twice.

TTS 384 · A: I would reproduce the original failure, then test the corrected behavior. For a duplicate-order bug, I would send two requests with the same operation ID and verify there is only one order.

TTS 386 · A: I would attach or propagate a correlation identifier and inspect logs or traces for that identifier. Then I would compare timestamps, error boundaries, and database effects.

TTS 388 · A: I would check the API contract, log the safe diagnostic details, and reproduce the request if appropriate. I would separate permanent validation failures from transient failures before deciding whether to retry.

TTS 390 · A: I would identify a stable business key for each imported record. Then I would use an appropriate unique constraint or upsert strategy. I would also test duplicate rows and repeated file uploads.

TTS 392 · A: V-Pulse is a payment-reliability demo built with Java, Spring Boot, PostgreSQL, Redis, and React. It uses simulated payment rails, not real bank integrations. The main learning problem is handling uncertain payment outcomes safely.

TTS 394 · A: The browser sends a stable operation key and payload through the BFF. The Java service validates the request and stores a processing instruction and its identity in a short transaction. It calls the simulated gateway outside that transaction, then finalizes the result in another transaction.

TTS 396 · A: No. A timeout means the caller did not confirm the result in time. A real provider might already have processed the request. V-Pulse parks uncertain work instead of blindly authorizing the payment again.

TTS 398 · A: Duplicate create uses the same merchant, key, and payload to retrieve the existing instruction. Replay means making another attempt to send an already known instruction to the gateway. A safe duplicate create does not automatically authorize a new gateway attempt.

TTS 400 · A: Replay needs explicit evidence that the previous attempt did not execute, such as a definite rejection or a call blocked before sending. A timeout or unknown outcome does not give that permission. The backend rejects unsafe replay even if the rail appears healthy now.

TTS 402 · A: A timeout limits how long we wait for a result. A circuit breaker stops calling a rail that repeatedly fails, while a bulkhead limits concurrent calls. A Redis rate limit controls how many new requests one merchant can make in a time window.

TTS 404 · A: Waiting for an external gateway inside a database transaction could hold locks for too long. V-Pulse commits instruction identity first, calls the gateway, and finalizes the result separately. This design requires explicit handling of crashes and uncertain outcomes between those steps.

TTS 406 · A: The repository includes integration tests that assert instruction state and simulated gateway call counts. One test confirms that a timed-out instruction cannot be replayed just because the rail recovers. Another verifies that a late result cannot overwrite a recovered database state.

TTS 408 · A: Its rails are simulators, so the tests do not prove real payment settlement behavior. Local deduplication and version checks do not guarantee exactly-once payments at a real provider. Reliable real-provider integration would need a provider contract for references, deduplication, status lookup, and reconciliation.

TTS 410 · A: Finalization checks that the instruction is still processing and has the expected version. A stale worker cannot overwrite a database state already changed by recovery. This database guard cannot undo an external provider side effect.

TTS 412 · A: The current limiter fails open: it allows requests to continue and records a metric. That favors availability, but it temporarily loses the quota protection. Merchant IDs are normalized for the budget, but choosing an ID is not proof of ownership.

TTS 414 · A: A testable acceptance criterion has a clear action, condition, and expected result. For example, a valid booking request should return a confirmed result within an agreed target under a defined test load.

TTS 416 · A: A technical output is something we build, such as an API or dashboard. A business outcome is the effect, such as fewer manual errors or faster processing. I would define a metric for the outcome.

TTS 418 · A: I would ask which workflow is slow, when the problem happens, and how many users are affected. Then I would inspect latency metrics, logs, and the business impact before proposing a fix.

TTS 420 · A: A symptom is what users notice, such as a slow screen. The business goal may be faster check-in or fewer staff errors. I would ask what outcome matters and how it will be measured.

TTS 422 · A: I would ask the customer to rank the workflows by value and risk. Then I would propose a small MVP that solves the most important problem first and leaves lower-priority automation for later.

TTS 424 · A: I would show the new evidence and revise my hypothesis. Then I would investigate other causes and update the plan. I should not defend an assumption after the data disproves it.

TTS 426 · A: I would ask them to walk me through the current process and the main pain point. Then I would clarify who uses the process, how often it fails, and what improvement would matter.

TTS 428 · A: I would write scenarios with clear inputs, conditions, and expected results. I would include at least one failure case and an agreed measure of success. The client should confirm these criteria before delivery.

TTS 430 · A: I would first ask who uses the workflow and what problem they face. Second, I would ask where the data comes from and which source is trusted. Third, I would ask how we measure success.

TTS 432 · A: I would choose the smallest workflow that delivers measurable value. It needs clear assumptions, a testable result, and a realistic scope. I would defer nonessential features.

TTS 434 · A: I would clarify whether we can use cached data, pause processing, or ask for manual review. I would not silently accept stale or unverified data when correctness matters.

TTS 436 · A: I would choose a metric linked to the customer’s goal, such as processing time, error rate, or manual work hours. I would measure it before and after deployment under comparable conditions.

TTS 438 · A: I would restate the new rule and identify which entities, states, APIs, and tests it affects. Then I would update the design and explain any extra cost or risk.

TTS 440 · A: I would clarify which source is authoritative and whether it can be delayed or incorrect. Then I would update the data flow, conflict rules, and tests. I would explain the new trade-off before continuing.

TTS 442 · A: I would reduce scope to one high-value workflow and reuse reliable existing components. I would identify the riskiest integration early and agree on what the demo must prove.

TTS 444 · A: I would compare their business impact, urgency, implementation cost, and dependencies. If priorities still conflict, I would ask the customer to decide based on explicit trade-offs.

TTS 446 · A: For practice, I would describe a Java backend project that handles business requests. I would explain the user problem, the main API flow, and one technical decision. I would only claim work that I actually did.

TTS 448 · A: I would explain how I reproduced the bug, what caused it, and what I changed. Then I would describe the test and its actual result. I would not claim the fix worked without evidence.

TTS 450 · A: First, I would explain the input and expected output. Then I would describe the main steps and data structure. Finally, I would give the time and space complexity and explain why.

TTS 452 · A: I would name the classes, features, and tests I personally worked on. For everything else, I would say that I reviewed or learned from it rather than claiming ownership.

TTS 454 · A: I would start with the user problem and the workflow the project supports. Then I would name the main backend responsibility and a result I can actually demonstrate. I would replace this practice outline with facts from my own project.

TTS 456 · A: I would name the endpoints, services, queries, or tests I wrote myself. I would separate my work from team contributions. I would be ready to open the relevant code and explain one decision.

TTS 458 · A: First, the client sends a request to an endpoint. The controller validates the input, and the service applies business rules. The repository accesses the database, and the API returns a result. For my real project, I must describe the actual classes and flow.

TTS 460 · A: I would connect the choice to a requirement such as relational consistency or read performance. Then I would explain one alternative and one trade-off. I would only say I chose a tool if I actually participated in that decision.

TTS 462 · A: A timeout may leave the operation's result unknown. I would describe the actual error handling, retries, and status checks implemented in my code. If those protections are missing, I would state that honestly as a limitation.

TTS 464 · A: I would identify the business invariant and show where the system enforces it. Possible mechanisms include a unique constraint, an atomic update, or persistent idempotency handling. I would describe only the mechanism that exists in my project.

TTS 466 · A: I would explain the symptom, how I reproduced it, and what evidence revealed the cause. Then I would describe the fix and the test that prevented a regression. I need a real example rather than an invented story.

TTS 468 · A: I would choose one concrete limitation supported by the current code. Then I would propose a small improvement and explain its benefit and cost. I would avoid promising a complete redesign without evidence.

TTS 470 · A: I would improve the highest-risk part first, based on evidence from tests or measurements. I would explain why that change matters and how I would verify it.

TTS 472 · A: The goal is to find two indices whose values add up to a target. A hash map lets us look up the needed complement in expected O(n) time with O(n) extra space. I would test duplicate values and negative numbers.

TTS 474 · A: V-Market locks inventory so two different checkouts cannot oversell stock. V-Core locks a column so task moves cannot exceed its WIP limit, while task versions detect stale edits. Both protect shared business invariants at the database boundary.

TTS 476 · A: V-Market reuses the checkout operation key to recover an existing order without deducting stock again. V-Pulse also deduplicates create requests, but a new gateway attempt needs separate permission. A payment timeout can leave the external outcome unknown, so blind replay is unsafe.

TTS 478 · A: For Java Backend concurrency, I would use V-Market's stock-locking checkout or V-Core's WIP rule. For FDE integration and uncertain downstream outcomes, I would use V-Pulse's simulated gateway workflow. I would choose the example I can explain from code and tests, without overstating my personal contribution.

TTS 480 · A: First, I would read the method name, parameters, and return type. Then I would trace the main branches and dependencies. Finally, I would run or write small tests to confirm my understanding.

TTS 482 · A: A missing requirement means the expected behavior was not clearly defined. A bug means the implementation does not meet an agreed requirement. I would confirm the expected behavior with the team.

TTS 484 · A: I would ask about authentication, request and response formats, errors, rate limits, and retry rules. I would also confirm whether repeated calls can create duplicate side effects.

TTS 486 · A: I would reproduce the actual behavior with a small request and record the evidence. Then I would ask the provider to clarify the contract and make our integration handle the verified behavior safely.

TTS 488 · A: I would write a characterization test for the current behavior, including important edge cases. Then I would refactor and run the tests again to check that behavior did not change unexpectedly.

TTS 490 · A: Could you repeat the last part a little more slowly, please? I want to make sure I understood the requirement before answering.

TTS 492 · A: I would identify the inputs, outputs, main branches, and side effects. Then I would run a small example and check edge cases. I would change one behavior at a time and rerun tests.

TTS 494 · A: I would start with official documentation and a small working example. Then I would integrate the minimum required feature and write tests for important behavior. I would ask for review where the risk is high.

TTS 496 · A: I would clarify the actors, main entities, and one important business rule. Then I would describe the API, database flow, and an error case. I would test the basic flow before adding more complexity.

TTS 498 · A: The most important invariant depends on the case. For a booking system, the same room must not be allocated to two active bookings for the same night. I would enforce this at the database boundary.

TTS 500 · A: I would clarify the external API contract and failure behavior. Then I would add a separate integration component, timeouts, and a way to check uncertain results without creating duplicates.

TTS 502 · A: I would enforce important local invariants in the database through suitable constraints or atomic operations. The service also validates business rules, but application checks alone may not handle concurrency.

TTS 504 · A: I would show tests for normal requests, invalid inputs, and concurrent conflicts. I would also report observed results and limitations. Tests provide evidence, but they cannot prove the absence of all bugs.

TTS 506 · A: I would clarify the actors, the capacity rule, and whether students may enroll twice. Then I would model Enrollment, define an endpoint, and protect capacity in the database. I would test two students competing for the last seat.

TTS 508 · A: I would not assume one local transaction covers both services. I would define the required consistency level and use an appropriate workflow with status tracking and compensation or reconciliation. Then I would test partial failures.

TTS 510 · A: A database transaction groups related operations into one logical unit. It can make local changes succeed or fail together. For example, booking creation and inventory updates should remain consistent.

TTS 512 · A: I would use a modular monolith for a small MVP because it is easier to build and deploy. The trade-off is that individual components are harder to scale or deploy independently.

TTS 514 · A: I would clarify the changed requirement before answering. Then I would explain what part of the design changes, why it changes, and which new test I would add.

TTS 516 · A: I would change my decision if measurements showed a different bottleneck or if business requirements changed. For example, very high independent load might justify separating one service.

TTS 518 · A: I would explain that the system first checks whether a room is free, then saves the reservation. It must prevent two customers from getting the same room for the same night.

TTS 520 · A: I would state the missing information and ask one focused clarification. If no answer is available, I would make a reasonable assumption and label it. Then I would explain how the design changes if the assumption is wrong.

TTS 522 · A: I would listen to the new constraint and compare it with my original assumption. Then I would explain whether I would keep or change the design and what trade-off follows. I would not defend a choice simply because I made it first. ---