Databases
Relational, NoSQL & Distributed Storage Engines
Databases store, manage, and query structured and unstructured data. Mastering storage engines, indexing strategies, and consistency models is critical for reliable backends.
Track Curriculum
Subtopics & Modules
SQL Fundamentals & Joins
SELECT queries, INNER/LEFT/RIGHT/FULL JOINs, GROUP BY aggregations, and subqueries.
Relational DBs (Postgres & MySQL)
Schema design, normalization (1NF-3NF), foreign keys, storage engines (InnoDB), and JSONB.
NoSQL & Document Stores
Document stores, MongoDB, aggregation pipelines, key-value stores, and schema-less flexibility.
Indexing & Query Optimization
B-Trees, Hash indexes, composite indexes, EXPLAIN ANALYZE, and covering queries.
Transactions & ACID Properties
Atomicity, Consistency, Isolation, Durability, isolation levels, and deadlock resolution.
Redis & In-Memory Caching
Redis data structures (Strings, Hashes, Lists, Sets, Sorted Sets), TTL, eviction policies, and cache patterns.
Database Sharding & Replication
Primary-Replica replication, read scaling, hash-based sharding, CAP theorem, and PACELC.
Interview Questions by Module Topic
Select a module to view its related questions, or explore all modules organized by seniority level
SQL Fundamentals & Joins
While developers write SQL starting with `SELECT`, relational database engines (PostgreSQL, MySQL, Oracle) process query clauses in a strict declarative pipeline order: 1. **FROM / JOIN**: Identifies target tables and executes join logic (cartesian product + join filters). 2. **WHERE**: Evaluates filter predicates row-by-row on the base data *before* grouping. 3. **GROUP BY**: Aggregates filtered rows into distinct bucket groups. 4. **HAVING**: Filters the aggregated groups using aggregate expressions (e.g. `COUNT(*) > 5`). 5. **SELECT**: Evaluates column expressions, scalar functions, and assigns column aliases (`AS total`). 6. **DISTINCT**: De-duplicates projected tuples. 7. **ORDER BY**: Sorts the final output rows. 8. **LIMIT / OFFSET**: Paginates and truncates the result set. Because the `WHERE` clause executes at Step 2 while column aliases are assigned in `SELECT` at Step 5, the alias does not exist yet when `WHERE` evaluates! In contrast, `ORDER BY` executes at Step 7, which is why column aliases *can* be referenced in `ORDER BY`.
-- ILLEGAL: Fails with "column total does not exist"
-- SELECT price * quantity AS total FROM orders WHERE total > 100;
-- CORRECT: Repeat expression or use CTE / Subquery
SELECT price * quantity AS total
FROM orders
WHERE (price * quantity) > 100
ORDER BY total DESC; -- Legal: ORDER BY runs after SELECT!🔍 Code Mechanics (SQL): WHERE executes at step 2 before SELECT runs at step 5; ORDER BY runs at step 7, allowing it to reference SELECT aliases.