Easy everything in Backend Dev, page 14
Data Pipelines: From Raw Data to Actionable Insights
A data pipeline is the plumbing for your data, moving it from raw sources to a refined state for analysis. It feeds dashboards and ML models by cleaning data from APIs and databases. The key footgun is choosing batch processing for real-time needs.
Amazon RDS: Managed Relational Databases in the Cloud
Amazon RDS is like hiring a DBA to manage your database's plumbing. It's for when you need a SQL database like PostgreSQL or MySQL without the hassle of patching and backups. The footgun is assuming it's 'serverless'—you still manage cost and performance.
Database as a Service (DBaaS): Rent, Don't Build
DBaaS is like leasing a database instead of owning it. A cloud provider handles the backups, patching, and scaling, so you can focus on your app. The main footgun is assuming "managed" means you can ignore configuration, query performance, and costs.
Connection String: Your App's Key and Address to Data
A connection string is your app's address and key to a data source. It bundles the host, port, database name, and credentials into a single string for a driver to use. The main footgun is committing credentials to version control by hardcoding the string in.
ODBC: The Universal Translator for Databases
ODBC acts as a universal translator, letting one application speak to many different relational databases. Your app uses the standard ODBC interface, and a specific "driver" handles the unique protocol for each database. The footgun is performance overhead.
JDBC: Java's Universal Translator for Databases
JDBC is Java's universal adapter for databases, letting your app speak SQL to any database via a standard API. It's used for connecting, querying, and managing transactions. The biggest footgun is building SQL strings directly; always use PreparedStatements.
Connection Pooling: Don't Re-Open, Reuse
A connection pool is a valet service for database access. Instead of creating a new connection for every request, you borrow a ready-made one and return it. This avoids costly setup/teardown in web apps.
Role-Based Access Control (RBAC) in Databases
RBAC bundles permissions into roles, like 'analyst' or 'admin', instead of assigning them to individuals. This simplifies managing who can read or write data in a database. The footgun is creating too many roles, making it as complex as individual permissions.
Differential Backups: Faster Backups, Simpler Restores
A differential backup saves all changes since the last full backup, making daily backups faster. To restore, you only need the full backup and the latest differential file. The footgun: each differential file grows larger until the next full backup is made.
Read Replicas: Scale Out Your Database Reads
A read replica is a read-only copy of your database that handles query traffic. Use it for read-heavy apps to prevent your primary DB from becoming a bottleneck. The footgun: replication is asynchronous, so reads from a replica can return slightly stale data.
Document Databases: Store Data as Flexible Objects
A document database stores data as self-contained objects, like JSON, instead of rows and columns. It's ideal for user profiles or product catalogs where each item might have different attributes. The footgun is treating it as a schema-less free-for-all.
Key-Value Store: The Simplest Database Model
A key-value store is a giant dictionary. You give it a unique key, like "user:123", and it returns the associated data. It's the foundation for caching and session management. The footgun is trying to query by value—it's built for key lookups only.
NoSQL: Databases Beyond Rigid Tables
NoSQL databases trade rigid tables for flexible models like documents or key-value pairs. This allows them to scale for massive, unstructured datasets from social media or IoT.
Nested Loop Join: The Brute-Force Database Join
A nested loop join is the brute-force way to match two tables. For each row in the first table, it scans every row in the second. It's simple and effective for small tables but its performance degrades quadratically on large datasets.
Database Pages: The Building Blocks of Your Data
A database page is the fundamental 8KB block for all storage. The database engine reads and writes entire pages, not single rows, for user data, indexes, and metadata. The key footgun: the physical order of rows on a page is not guaranteed.
Row vs. Columnar Storage: Organizing Data for Speed
Row stores group data by record, like a phone book entry. Column stores group by attribute, like separate lists for all names. Use row stores for transactions (OLTP), but for analytics (OLAP), they force you to read unneeded data from disk.
Storage Engine: The Database's Filing System
A database's storage engine is its specialized filing system, handling how data is physically written to and read from disk. Different engines optimize for different tasks, from fast writes to complex queries.
Row Mode vs. Batch Mode Execution in SQL Server
Row mode processes data one row at a time, like a checklist. Batch mode processes chunks of rows together for vectorized speed. Row mode is classic for OLTP, while batch mode shines in data warehousing for large scans.
B-Tree: The Workhorse of Database Indexes
A B-tree is a self-balancing tree that keeps data sorted for fast lookups, generalizing a binary search tree by allowing nodes to have many children. It enables searches, insertions, and deletions in logarithmic time, making it ideal for large datasets.
Query Execution Plan: The Database's Road Map
A query execution plan is the database's internal strategy for fetching your data. It's the recipe it creates before running your SQL. This plan determines whether to use an index or scan a whole table, directly impacting performance.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles