Architecture
376 bites tagged Architecture — interview questions with model answers, and 60-second explainers.
Database Parameter Tuning: Beyond the Defaults
Database defaults are a compromise. Parameter tuning tailors the database to your specific workload, hardware, and reliability needs. It's used to optimize memory, WAL settings, or query planning.
Database Disaster Recovery: Planning for Total Failure
Database Disaster Recovery (DR) assumes your primary site is gone for good, focusing on restoring service at a secondary location. It's for critical systems where regional outages are unacceptable. The footgun is confusing DR with High Availability (HA).
Database High Availability: Surviving Server Failure
High Availability (HA) means having a hot standby database ready to take over instantly upon failure. It's essential for critical systems like payment gateways where downtime is unacceptable.
Database Encryption: Protecting Data at Rest
Database encryption turns your data into useless gibberish for anyone without the key. It protects sensitive data at rest, like PII or financial records, from direct theft of the database files.
Point-in-Time Recovery: Rewind Your Database to a Specific Second
Point-in-Time Recovery (PITR) is a database time machine, restoring data to a specific second, not just the last snapshot. It's crucial for reversing application-level errors.
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.
Paxos: Achieving Consensus in Unreliable Networks
Paxos is like a legislature agreeing on a law with unreliable messengers. It lets servers agree on a value (like a transaction) despite failures. It’s used in distributed databases for consistency, but its complexity is its biggest footgun; never implement it…
Consistent Hashing: Resizing Distributed Systems Gracefully
Consistent hashing prevents mass data reshuffling when servers are added or removed. It maps keys to servers on a logical ring, so only a fraction of keys need remapping during a resize. This is crucial for distributed caches to avoid stampedes.
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.
MOLAP: A Pre-Computed Cube for Fast Analytics
MOLAP pre-calculates business data into a multi-dimensional "cube" for near-instant analytics. Use it for BI dashboards requiring fast responses to complex queries. The footgun: the cube is a static snapshot, and building it can be slow and rigid.
Dimension Tables: The 'Who, What, Where, When' of Your Data
Dimension tables provide the descriptive context—the 'who, what, where, when'—for raw numbers in a fact table. They are the backbone of data warehouses, letting you slice sales data by product or region. The footgun is polluting them with transactional data.
Fact Table: The Numbers in Your Data Warehouse
A fact table is the ledger of business events, recording what happened and how much. It's the core of a data warehouse, holding sales figures or page views. The footgun is storing descriptive text here; that belongs in linked dimension tables.
CRDTs: Syncing Data Without Locks or Conflicts
CRDTs are data structures where updates can be applied in any order and reach the same state, avoiding locks. They enable offline editing in collaborative apps and distributed databases.
Polyglot Persistence: Use the Right Database for the Job
Polyglot persistence means using multiple, specialized data stores in one system. Instead of one database handling everything, you might use a relational DB for transactions, a document DB for profiles, and a graph DB for connections.
Time Series Database: A Logbook, Not a Filing Cabinet
A Time Series Database (TSDB) is a specialized logbook for data that happens over time, like server metrics or sensor readings. It's built for high-speed writes and fast range queries. The footgun: don't use it for relational data like user profiles.
Database Sharding: Splitting Data for Scale
Sharding splits a database across multiple servers, like dividing a phone book into A-M and N-Z volumes. It's used when a single server can't handle the data size or write load. The footgun is that querying across shards is complex and slow.
Graph Databases: When Relationships Are the Data
A graph database treats connections between data as first-class citizens. It's ideal for social networks or fraud detection where you query relationships by traversing links. The footgun is using it for simple tabular data where a relational DB is faster.
Wide-Column Store: Flexible Schema for Massive Datasets
A wide-column store is like a spreadsheet where each row can have its own unique columns. It's ideal for sparse data like user profiles or IoT readings. The footgun is thinking it's just a relational table with many columns—the flexibility is the point.
Eventual Consistency: Availability Now, Correctness Later
Eventual consistency prioritizes availability by letting replicas temporarily disagree. If updates stop, all nodes will eventually converge on the same value.
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.
Get Architecture bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.