Java Programming Questions

synchronized vs volatile vs AtomicInteger

• synchronized: provides mutual exclusion and memory visibility. Guarantees atomicity for a block/method and that entering a synchronized block sees prior writes. Use when multiple operations must be atomic (e.g., check-then-act).
  Example: synchronizing updates to a List or performing composite updates on multiple fields.

• volatile: guarantees visibility and ordering for single reads/writes of a variable but not atomicity for compound ops. Use for flags or state switches.
  Example: a boolean shutdown flag read by multiple threads.

• AtomicInteger (java.util.concurrent.atomic): provides atomic operations (get, incrementAndGet, compareAndSet) and weaker locking overhead. Guarantees atomicity for its methods and volatile-like visibility.
  Example: high-throughput counters, sequence generators, or non-blocking algorithms.

Choose synchronized for compound critical sections, volatile for simple visibility, AtomicInteger for lock-free numeric updates.

Transaction anomalies (brief)

• Dirty read: Tx A reads uncommitted writes of Tx B. Prevented by READ COMMITTED+.
• Non-repeatable read: A reads same row twice and sees different committed values.
• Phantom read: A re-executes a range query and sees newly inserted rows.
• Lost update: concurrent writes overwrite each other without awareness.
• Write skew: two concurrent transactions read overlapping data and write non-conflicting rows causing invariant break.

Bank transfer isolation strategy

• Prefer READ COMMITTED or REPEATABLE READ with explicit SELECT ... FOR UPDATE on account rows to avoid lost updates while keeping throughput.
• Application patterns:
  • Use SELECT FOR UPDATE to lock source and destination rows in a fixed order to avoid deadlocks.
  • Alternatively, optimistic locking with version column: read+check version then UPDATE ... WHERE version = ?; retry on mismatch.
  • Serializable isolation prevents anomalies but may increase serialization failures; use if invariants are complex.

Postgres vs MySQL

• Postgres: REPEATABLE READ implements true snapshot isolation; SERIALIZABLE provides predicate locking and higher safety. SELECT FOR UPDATE blocks and is reliable.
• MySQL InnoDB: REPEATABLE READ uses next-key locking; behavior differs: some phantom protection exists. MySQL's gap locks can block more, causing potential contention.
• Trade-offs: pessimistic locking (FOR UPDATE) is simpler and predictable with lower retry rates; optimistic locking scales better under low contention but requires retries. Choose based on expected concurrency and latency SLA.

Primary key vs Unique constraint vs Foreign key

• Primary Key: Uniquely identifies rows, not null, usually clustered/indexed. Use case: id column for entity lookups. Performance: fast primary-key lookups; inserts/updates maintain index cost. JPA: @Id (often @GeneratedValue).

• Unique Constraint/Index: enforces uniqueness on column(s) but allows nulls (DB-dependent). Use case: email must be unique. Performance: supports fast equality lookups; adds overhead on writes. JPA: @Column(unique = true) or @UniqueConstraint on @Table, and @NaturalId in Hibernate.

• Foreign Key: enforces referential integrity between tables. Use case: order.customer_id references customers(id). Performance: adds checks on inserts/updates/deletes and may block cascading deletes; supports join optimizations when indexed. JPA: @ManyToOne with @JoinColumn; database-level FK is separate but generated by schema tools.

Trade-offs: more indexes = faster reads, slower writes. Use proper indexing and selectively enforce constraints where integrity matters.

Exception handling best practices in Java backends

• Differentiate recoverable vs fatal: recoverable (validation errors, transient network failures) should be propagated as domain/checked exceptions or retried; fatal (data corruption, OOM) should result in fail-fast and alerts.

• Exception hierarchy: define base AppException (runtime) with subtypes (NotFoundException, BadRequestException, TransientException). Keep payload small and avoid leaking internals.

• Map to HTTP in Spring Boot: use @ControllerAdvice with @ExceptionHandler mapping NotFound -> 404, Validation -> 400, Transient -> 503, generic -> 500. Include standard error body with code, message, requestId.

• Logging without leaking secrets: log stack traces server-side with requestId; sanitize messages (no tokens, PII). For client responses, return safe, user-friendly messages. Use structured logs and correlation IDs for debugging.

High-level architecture

• API layer (stateless Java services) → ingress load balancer → Order validation service → Inventory/Payment coordinator → Order write DB + async workers for fulfillment.

Partitioning & datastore

• Relational DB sharded by customer_id or order_id prefix (range or consistent-hash). Use per-shard leader for strong consistency. Read replicas for queries.
• Keep hot inventory counters in a strongly-consistent service: either co-locate inventory with shard or use distributed transactional store (sharded RDBMS with two-phase commit avoided).

Synchronous vs asynchronous

• Synchronously: reserve inventory and persist order in single shard transaction to ensure strong consistency. Charge payment synchronously or via reserved authorization.
• Asynchronously: fulfillment, notifications, analytics via Kafka.

Scaling & throughput

• Use front-tier autoscaling, pool DB connections per shard; horizontally scale Java workers; employ batching for writes where possible.
• Achieve 5k RPS by partitioning orders across many DB shards; ensure each shard handles subset <200ms writes.

Idempotency

• Idempotency keys per client stored in shard local table to dedupe retries.

Availability & metrics

• Measure p95/p99 latency, DB commit latency, tail latency, orders/sec, success rate. Use chaos tests and load tests.

Trade-offs & failure modes

• Strong consistency reduces throughput and increases cross-shard complexity. Sharding reduces contention but increases operational complexity. Payment/inventory partial failures require compensating actions and clear state machine.