databases
10 minSQL Query Recipes: Joins, Grouping, Window Functions, and Safe Pagination
Build common analytics queries while avoiding duplicate rows, incorrect aggregates, unstable pages, and cross-dialect surprises.
Search the library
10 matching resultsArticles and interview answers
Q&A
Q&AWhy did a SQL join unexpectedly multiply my totals?
A one-to-many join changes row grain; multiple child joins can multiply each other.
Read the concise answer
Check the cardinality of each join. Joining one order to several lines produces multiple rows per order; joining another one-to-many table can multiply those rows again. Aggregate each relation to the intended grain before joining or use EXISTS when you only need to test presence. DISTINCT is not a reliable repair for incorrect join logic.
kubernetes
5 minKubernetes CronJobs: Timezones, Missed Starts, and Duplicate Work
Operate a scheduled report as a reconciled workload with explicit timezone, lateness limits, and application-level deduplication.
Q&A
Q&AWhen should you choose a Python list, tuple, or set?
Base the choice on ordering, mutation, duplicates, and membership operations.
Read the concise answer
A list is ordered, mutable, and permits duplicates. A tuple is an immutable sequence suited to fixed records, though named structures can improve readability. A set stores unique hashable values and is useful for membership; do not use it when output order or duplicates are part of the contract.
distributed systems
9 minIdempotency and the Transactional Outbox: Making Retries Safe
Learn why network retries create duplicate effects and how idempotency keys and an outbox close common reliability gaps.
Q&A
Q&AWhy are Kafka offsets and commit timing so important?
Offsets are the durability checkpoint. Commit too early and you lose work; commit too late and you duplicate it.
Read the concise answer
Kafka commits represent when the consumer believes work has been finished. If the offset is committed before the business effect is truly durable, a crash can lose data. If it is committed only after a delay, the application may re-process messages when the consumer restarts. The correct strategy is to commit only after the state change is stored successfully and the work is idempotent enough to recover from retries.
Q&A
Q&AWhat identity should a delayed scheduled-job retry preserve?
Preserve the logical job and intended window, not the retry start time.
Read the concise answer
A logical run names the business partition; attempt IDs name executions of that run. Commit completion with the effect when they share storage, and handle remote effects with an explicit duplicate or reconciliation protocol.
Q&A
Q&AWhy does a relational table need a primary key?
A primary key gives each row a stable identity; it does not replace domain-level uniqueness constraints.
Read the concise answer
A primary key lets the database and applications refer to one row unambiguously and lets foreign keys express relationships. Add separate unique constraints for business rules such as one account per email. A generated ID alone does not prevent duplicate domain entities.