Core Technical Concepts for Backend Engineering Interviews

Database Normalization Principles

Relational database design relies on normalization rules to minimize redundancy and preserve data integrity across tables. The foundational guidelines include:

  • First Normal Form (1NF): Enforces atomicity. Every column must contain indivisible values, eliminating repeating groups or nested structures within a single field.
  • Second Normal Form (2NF): Requires compliance with 1NF plus full functional dependency. Non-key attributes must depend entirely on the composite primary key, not just a portion of it. This prevents partial dependencies.
  • Third Normal Form (3NF): Builds upon 2NF by removing transitive dependencies. Non-key fields cannot rely on other non-key fields; every attribute must depend solely on the primary key and nothing else.

MySQL Index Architectures

Indexes optimize query performance by reducing full table scans. Common implementations include:

  • Primary Key Index: Automatically applied to the primary key column. InnoDB organizes data physically via a B+ tree based on this key. If absent, a hidden clustered index is generated.
  • Secondary Index: Created on arbitrary columns using ALTER TABLE ... ADD INDEX. Useful for frequent filtering, though low-cardinality fields often yield poor performance gains due to high selectivity costs.
  • Prefix Index: Truncates string indexing by specifying a character limit (column_name(5)), optimizing memory usage for large VARCHAR or TEXT columns. Numeric columns cannot utilize this approach.
  • Composite Index: Spans multiple columns following the leftmost prefix rule. Queries must reference the initial column(s) in sequence to leverage the index efficiently.
  • Full-Text Index: Utilizes inverted indexes for rapid lexical searches across large text blocks. Supported natively in MyISAM and InnoDB (since 5.6.4).
  • Unique Index: Guarantees distinct values per row while permitting NULL entries. Often used for logical constraints rather than pure performance tuning.
  • Spatial Index: Optimized for geographic data models compliant with OpenGIS standards (MySQL 5.7+).
-- Example: Creating various index types
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    status VARCHAR(50) NOT NULL,
    customer_email VARCHAR(255),
    description TEXT
);

-- Standard secondary index
ALTER TABLE orders ADD INDEX idx_status (status);

-- Prefix index for large strings
ALTER TABLE orders ADD INDEX idx_customer_prefix (customer_email(20));

-- Composite index adhering to leftmost prefix rule
ALTER TABLE orders ADD INDEX idx_composite (status, customer_email);

Transaction Consistency & Isolation Mechanics

Reliable state transitions require adherence to ACID properties:

  • Atomicity: Operations act as an indivisible unit; partial failures trigger automatic rollback.
  • Consistency: Transitions maintain predefined rules and constraints, moving the system from one valid state to another.
  • Isolation: Concurrent executions remain shielded from internal intermediate states.
  • Durability: Committed changes survive system crashes through write-ahead logging.

Concurrent access demands configurable isolation tiers:

Level Dirty Read Non-Repeatable Read Phantom Read Locking Overhead
READ UNCOMMITTED Possible Possible Possible None
READ COMITTED Prevented Possible Possible Row-level snapshots
REPEATABLE READ Prevented Prevented Possible (default in MySQL) MVCC + Gap locking
SERIALIZABLE Prevented Prevented Prevented Full range locks

Higher isolation guarantees improve data safety but degrade throughput due to extended lock retention. Phantom reads specifically occur when a subsequent query within the same transaction reveals newly inserted rows matching previous filters, despite no updates to existing records.

Performance Measurement Metrics

Evaluating system capacity requires tracking distinct telemetry points:

  • Queries Per Second (QPS): Requests processed against a specific endpoint per second. Calculated as ConcurrentConnections / AverageResponseTime.
  • Transactions Per Second (TPS): Complete business cycles handled per second (request reception → processing → response delivery).
  • Concurrency: Simultaneous active connections or pending operations awaiting CPU allocation.
  • Page Views (PV): Cumulative page loads triggered by user refreshes or navigations.
  • Unique Visitors (UV): Distinct client identities accessing resources within a timeframe, typically tracked via session cookies or IP hashing.

Throughput ceilings emerge when either QPS or concurrent connection counts hit hardware/software limits. Exceeding these thresholds triggers context-switching overhead and memory pressure, paradoxically lowering effective throughput.

Concurrency Anomalies Explained

Distributed execution introduces specific consistency challenges:

  • Dirty Read: Consuming uncommitted modifications that may subsequently roll back, exposing transient or invalid state.
  • Non-Repeatable Read: Discrepancies between sequential fetches of the same record due to external commit operations altering row contents.
  • Phantom Read: Appearance of new rows satisfying previous WHERE clauses after inserts/deletes by committed transactions, altering dataset cardinality without modifying existing entries.

Modern relational engines default to REPEATABLE READ (MySQL/MariaDB) or READ COMMITTED (PostgreSQL/Oracle) to balance safety and velocity. Understanding these boundaries dictates appropriate index placement and transaction scoping.

Guaranteeing Endpoint Idempotency

Stateless APIs executing duplicate requests must produce identical outcomes regardless of call frequency. POST endpoints lack inherent repeatability and require explicit safeguards:

  1. Token-Based Validation: Pre-generate cryptographically secure tokens stored in Redis. Submit alongside payloads; server validates existence then atomically removes it.
  2. Optimistic Locking: Embed version counters in update queries. Failing version checks prevent stale-overwrite scenarios.
  3. Deduplication Tables: Insert request identifiers into constraint-enforced lookup tables prior to business logic execution. Conflicting attempts halt gracefully.
  4. Database Constraints: Rely on unique keys to reject duplicate insertions at the storage layer.
  5. Client-Side Guards: Disable submission buttons post-initial click to prevent accidental double-submission.
import redis
import uuid

class IdempotencyGuard:
    def __init__(self, cache_client: redis.Redis, ttl: int = 3600):
        self.cache = cache_client
        self.ttl = ttl

    def acquire(self, operation_id: str) -> bool:
        key = f"idempotency:{operation_id}"
        return bool(self.cache.set(key, "executing", nx=True, ex=self.ttl))

    def release(self, operation_id: str) -> None:
        key = f"idempotency:{operation_id}"
        self.cache.delete(key)

# Usage simulation
guard = IdempotencyGuard(redis.Redis())
req_id = str(uuid.uuid4())

if guard.acquire(req_id):
    try:
        # execute_payment_logic()
        pass
    finally:
        guard.release(req_id)
else:
    raise RuntimeError("Duplicate execution attempt detected")

Python Concurrency Controls

The Global Interpreter Lock (GIL) restricts CPython execution to a single thread per process. Originally implemented to simplify memory management and garbage collection synchronization on single-core architectures, the GIL now acts as a bottleneck for CPU-bound workloads despite modern multicore systems.

Task profiling dictates threading strategies:

  • CPU-Bound Scenarios: Heavy computations exhaust processor cores sequentially under multithreading. Multiprocessing bypasses the GIL by spawning isolated interpreter instances, enabling true parallelism.
  • I/O-Bound Scenarios: Network calls, disk reads, or data base queries relinquish control during wait states. Threads efficiently pipeline these waits, maximizing utilization without requiring heavy process overhead.

Web frameworks like uWSGI leverage hybrid models (worker processes × threads per worker) to balance memory footprint against request handling capacity. Asynchronous runtimes further optimize this paradigm by managing cooperative multitasking within a single thread/event loop.

Memory Management & Garbage Collection

Python automates resource deallocation primarily through reference counting: objects track live pointers incrementally and decrement upon dereference. Zero references trigger immediate memory liberation. Cyclic references break pure count-based collection, necessitating supplementary algorithms:

  • Mark-and-Sweep: Traverses reachable object graphs from root references. Unmarked nodes represent orphaned cycles eligible for destruction.
  • Generational Collection: Categorizes live objects into three cohorts based on survival duration. Younger generations undergo frequent sweeps, while older ones are scanned less aggressively, optimizing pause times during long-running services.

Dynamic Code Modification Techniques

Monkey patching alters runtime behavior by swapping classes, methods, or module references mid-execution. Since Python treats functions as first-class attributes, direct reassignment modifies target objects transparently:

import json

# Swap standard library parser with faster alternative
import ujson
json.loads = ujson.loads
json.dumps = ujson.dumps

print(json.loads('{"key": "value"}')) # Executes ujson internally

This pattern proves valuable for hotfixing third-party dependencies, injecting test mocks globally, or overriding blocking network wrappers with asynchronous equivalents. Caution remains essential to avoid unexpected side effects in production environments.

Runtime Introspection (Reflection)

Reflection enables programmatic interaction with objects using string-based member resolution. Built-in helpers facilitate dynamic property management:

  • getattr(obj, attr_name): Retrieve value or method reference.
  • hasattr(obj, attr_name): Verify existence safely.
  • setattr(obj, attr_name, value): Assign or modify properties.
  • delattr(obj, attr_name): Remove dynamically attached members.

Frameworks heavily utilize introspection for routing dispatchers, serializer field mapping, and plugin loading. It allows decoupling static definitions from execution paths.

Transport Layer Security Protocols

HTTP facilitates plain-text communication over port 80, leaving data vulnerable to interception, tampering, and spoofing attacks. HTTPS encrypts payloads using TLS/SSL handshakes negotiated before application-layer exchange begins. Operating securely on port 443, it authenticates server identity via certificates, esstablishes encrypted tunnels, and verifies message integrity through cryptographic hashes. This encryption layer sits between the transport socket and HTTP protocol handler, ensuring confidentiality and trust without altering underlying request semantics.

Tags: database MySQL python Concurrency WebSecurity

Posted on Thu, 22 Oct 2026 16:19:47 +0000 by KrisCons