Tech Jargon - Decoded

What is an Endpoint? An endpoint is a specific URL used by an API to receive requests. It is the final "touchpoint" where a client application interacts with a server to perform a task. How it works: • A client sends a request (GET, POST, etc.) to a unique web address. • The server listens at this specific address for incoming signals. • Once the request hits the endpoint, the server triggers a specific function. • The server processes the request and sends back a response (data). Problem it solves: • It provides a structured way to access different server functions without them overlapping. • Without endpoints, a server wouldn't know which specific action or data the client is asking for. Simple Scenario: To fetch a list of items, an app calls /api/items. To delete an item, it calls /api/delete. Each unique path is a separate endpoint dedicated to one job.

What is GraphQL? GraphQL is a query language and runtime for APIs that allows clients to request specific data from a server. How it works: • Schema: The server defines a blueprint of available data types and fields. • The Query: The client sends a request listing the exact fields it needs. • Execution: The server validates the query against the schema and returns a JSON response matching the request structure. What it solves: • Over-fetching: Prevents downloading unnecessary data that slows down the app. • Under-fetching: Eliminates the need to make multiple API calls to get related data. Simple Scenario: Instead of calling /users/1 and /posts/1 separately, a client sends one query to get the name and post_title in a single round-trip. This reduces network overhead and improves performance.

What is a REST API? It is a set of rules that allows two computer systems to communicate over the web using the HTTP protocol. It acts as a standard interface for exchanging data between a client and a server. How it works: • Request: The client sends a request to a specific URL (Endpoint) using methods like GET (to read), POST (to create), PUT (to update), or DELETE. • Processing: The server receives the request, identifies the action, and retrieves or modifies data in the database. • Response: The server sends back a response code (like 200 for success) and the requested data, usually in JSON format. Problem it solves: It fixes system incompatibility. Different softwares (like a Java backend and a React frontend) can talk to each other easily because they all use standard HTTP rules. Simple Scenario: A mobile app needs to show a user's profile. It sends a GET request to the server's URL. The server fetches the user details and sends them back as a small text file (JSON) for the app to display.

What is an API? API stands for Application Programming Interface. It is a set of rules that allows two different software programs to communicate and exchange data with each other. How it works: • Request: One application (the client) sends a message to a specific URL called an endpoint. • Processing: The receiving application (the server) interprets the request and retrieves the required information from its database. • Response: The server sends the data back to the client, usually in a structured format like JSON. Problem it solves: It removes the need to build complex features from scratch. It allows developers to use existing data or services securely without needing access to the original source code or private databases. Simple Scenario: A travel app wants to show flight prices. It sends a request to various airlines' APIs. The APIs return the latest price data, which the app then displays to the user.

What is the N+1 Query Problem? It’s a performance issue where an application makes N+1 database calls to fetch data that could have been retrieved in just one query. It usually happens when using ORMs to fetch related records. How it works: 1. You run 1 query to get a list of parent records (e.g., Users). 2. For each parent record found (let's say N records), the code runs an additional query to get its child data (e.g., Profiles). 3. Total queries = 1 (initial) + N (one for each item). The Scenario: If you need to display 20 Users and their Profiles: - The app runs 1 query to get 20 users. - Then it runs 20 separate queries to fetch each user's profile. - This creates 21 database hits, which is slow and inefficient. How to fix it: It is solved by Eager Loading. Instead of fetching children one by one in a loop, you use a JOIN or an IN clause to fetch all related data in a single request.

What is Connection Pooling? It is a technique to keep a cache of database connections open so they can be reused for future requests. Problem it solves: Opening a new connection is "expensive." It involves a TCP handshake and authentication every single time, which slows down the application and consumes heavy server resources. How it works: • Initialization: A "Pool Manager" creates a set of connections when the app starts. • Borrowing: When your code needs to run a query, it asks the pool for an existing idle connection. • Reusing: After the query finishes, the connection isn't closed; it is simply released back to the pool. • Waiting: If all connections are busy, new requests wait until one becomes free. Use Case: In an API receiving 500 requests/sec, pooling prevents the database from crashing due to constant login/logout overhead, keeping the app fast and stable.

What is a Deadlock in Database Systems? A deadlock is a situation where two or more transactions are stuck forever because they are waiting for each other to release locks. Neither can proceed, creating a permanent halt. How it works: • Transaction A holds a lock on Row 1 and needs Row 2. • Transaction B holds a lock on Row 2 and needs Row 1. • Since neither will release their current lock until they get the next one, they wait indefinitely. Problem it solves: Deadlock detection prevents the system from freezing forever. The DBMS identifies the circular dependency and automatically "kills" (rolls back) one transaction so the others can finish. Scenario: • T1: Locks Account_A • T2: Locks Account_B • T1: Requests lock on Account_B (Waiting...) • T2: Requests lock on Account_A (Waiting...) Result: Circular wait detected.

What is a Database Lock? A mechanism that prevents multiple users or transactions from modifying the same piece of data at the exact same time. It ensures that data remains consistent and accurate. How it works: • When a transaction starts editing a row or table, the database marks it as "locked." • If another transaction tries to edit that same data, the database makes it wait in a queue. • Once the first transaction is finished (via Commit or Rollback), the lock is removed. • The next transaction in line then gains access and applies its changes. Problems it solves: • Lost Updates: Prevents two users from overwriting each other's changes. • Inconsistency: Stops data from being corrupted by simultaneous writes. Scenario: Two processes try to decrease a stock count of "1" at the same time. The lock forces Process B to wait until Process A finishes. Process B then sees the count is "0" and cannot proceed, preventing negative stock.

What is Strong Consistency? It is a guarantee that once a data update is confirmed, every subsequent read across all nodes will return that exact updated value. How it works: • When a write occurs, the system ensures all replicas are updated before the operation is marked as successful. • It prioritizes accuracy over speed by forcing nodes to synchronize immediately. • This ensures that no node in the system lags behind or holds outdated information. Problem it solves: • Stale Reads: Prevents users from seeing old data after an update has been made. • Data Inconsistency: Stops different servers from showing conflicting values for the same record. Simple Scenario: If you update a data record from "A" to "B", any system request arriving a millisecond later—regardless of which server it hits—is guaranteed to see "B".

What is Eventual Consistency? It is a data consistency model where all nodes in a distributed system will eventually show the same data, but not immediately after an update. How it works: - You send an update to one node (Server A). - Server A saves the data and tells you it's done. - In the background, Server A starts pushing this update to Server B and Server C. - For a brief moment, reading from Server B might show old data. - Once the background sync finishes, all nodes become consistent. Problem it solves: - High Latency: It prevents the system from being slow because it doesn't wait for every single node to confirm the write. - Availability: The system remains functional even if some nodes are temporarily disconnected during the sync. Simple Scenario: You update a variable from 10 to 20 on Node 1. If someone queries Node 2 at the exact same millisecond, they might still see 10. A few seconds later, once the sync is complete, Node 2 will also return 20.

What is Replication? Replication is the process of storing identical copies of data across multiple servers or nodes at the same time. How it works: • One server (Leader) receives a data write or update. • It automatically sends this change to other servers (Followers). • Every server updates its own local storage to match. • All nodes eventually hold the exact same version of the data. Problems it solves: • Data Loss: If one server's hard drive fails, the data is still safe on others. • System Downtime: If the main node crashes, the system stays online using a replica. • High Latency: Spreads the workload so no single server gets overwhelmed. Use Case: If a system has 1000 users requesting data, the load is split across 4 replicated servers instead of hitting just 1, keeping the response time fast.

What is Sharding? Sharding is a database architecture pattern that scales data horizontally by splitting a giant dataset into smaller, manageable chunks called "shards." How it works: • Data is distributed across multiple independent servers instead of one. • A Shard Key (like a UserID) is used to determine which server stores a specific row. • Each server has the same structure (schema) but holds different rows of data. Problem it solves: • Prevents a single server from crashing due to storage limits or high traffic. • Removes performance bottlenecks by allowing parallel processing across multiple machines. Simple Scenario: In a system with 10 million users, Server A can store IDs 1 to 5 million, while Server B stores 5 million to 10 million. This distributes the load and speeds up every search.

What is the CAP Theorem? It states that a distributed system can only provide two out of three properties at the same time: • Consistency (C): All nodes see the same data simultaneously. • Availability (A): Every request gets a response, even if some nodes are down. • Partition Tolerance (P): The system works even if the network fails between nodes. How it works: Since network failures (Partitions) are inevitable, you must choose: - CP: You favor Consistency. If nodes can't talk, the system stops responding to keep data accurate. - AP: You favor Availability. The system stays online, but nodes might show different data versions. Problem Solved: It helps engineers decide the right trade-off for a database based on whether they prioritize perfect data or 100% uptime. Scenario: When Node A cannot sync with Node B due to a wire cut, the system must either block the user from writing (CP) or allow the write and fix the mismatch later (AP).

What are ACID properties in a Database? ACID is a set of four rules that ensure database transactions are processed reliably and the data stays accurate. How it works: • Atomicity: The "All or Nothing" rule. If any part of a transaction fails, the entire operation is rolled back to the start. • Consistency: Data must follow all predefined validation rules and constraints before and after the transaction. • Isolation: Multiple transactions can run at once without interfering with each other. They behave as if they happened one by one. • Durability: Once a transaction is committed, it is permanently saved on the disk and won't be lost even during a system crash. Problem it solves: It prevents data corruption, partial updates, and "dirty reads" where one process sees half-finished data from another. Scenario: When subtracting a value from Table A and adding it to Table B, ACID ensures that if the system fails halfway, Table A is restored so no data simply disappears.

What is a Database Transaction? It is a sequence of one or more operations treated as a single unit of work. It follows the "all or nothing" principle to ensure data integrity. How it works: • Start: The system marks the beginning of the sequence. • Execute: All operations (like Insert, Update, or Delete) are performed in a temporary state. • Commit: If every step succeeds, the changes are saved permanently to the database. • Rollback: If any single operation fails, the system undoes all previous steps in that sequence, returning the data to its original state. Problem it solves: It prevents "partial updates." Without transactions, if a system crashes halfway through a multi-step task, your data would be left in a broken or inconsistent state. Use Case Scenario: Updating two related tables (Table A and Table B). A transaction ensures that if Table A is updated but the update to Table B fails, the changes in Table A are automatically reversed so the tables remain synced.

What is a Topic Index? A topic index is a structured mapping that links specific identifiers or keys to their exact physical location (offset) on a disk or in memory. How it works: • The system maintains a separate, smaller file or table containing "Topic Keys" and "Memory Addresses." • Instead of searching through the entire raw dataset, the system reads the index first. • Once the key is found, it retrieves the pointer and jumps directly to that byte offset to read the data. Problems it solves: • Eliminates the need for "Linear Scanning" (reading every bit of data from start to finish). • Dramatically reduces I/O operations and latency during data retrieval. Use Case Scenario: In a log storage system, if you request data for a specific "Transaction ID," the index provides the exact line number or memory block where that ID is stored, allowing an instant jump to that data point.

What is Query Optimization? It is the process of selecting the most efficient way to execute a database query to get results as fast as possible using minimal resources. How it works: • Parsing: The engine checks the SQL syntax and translates it into a format it understands. • Evaluation: It looks at table sizes, available indexes, and data distribution. • Plan Generation: It creates multiple "Execution Plans" (different paths to reach the data). • Selection: It picks the plan with the lowest "cost" in terms of CPU and memory usage. Problems solved: • Prevents high latency and slow response times. • Reduces unnecessary disk I/O and server load. • Stops the database from scanning millions of rows when it doesn't need to. Simple Scenario: Searching for a specific User_ID in a table of 5 million rows. Without optimization, the system might read every single row one by one. With optimization, it uses an Index to jump directly to the exact record.

What is ORM (Object-Relational Mapping)? ORM is a technique that lets you interact with a database using your favorite programming language (like Python or JS) instead of writing raw SQL. It acts as a bridge between your code and the data. How it works: • Mapping: Database tables are treated as Classes, and table rows are treated as Objects. • Translation: When you call a method in your code, the ORM automatically converts that action into an SQL query. • Syncing: It handles the data flow, ensuring that changes made to an object are updated in the actual database table. Problems it solves: • No need to write repetitive, messy SQL strings inside your code. • Fixes the "mismatch" between object-oriented code and relational tables. • Prevents common security issues like SQL Injection automatically. Use Case Scenario: Instead of manually typing SELECT * FROM users WHERE id=5;, you simply write User.find(5) in your code. The ORM handles the rest.

What is NoSQL? It is a non-relational database system that stores data without using fixed tables, rows, or columns. It is designed for large-scale, unstructured data. How it works: - It uses flexible formats like JSON documents, key-value pairs, or graphs. - There is no predefined schema; you can add new fields to a single record at any time. - Data is distributed across many servers (horizontal scaling) rather than one big server. Problem it solves: - Schema Rigidity: Traditional databases break if you try to save data that doesn't fit the table structure. NoSQL handles changing data shapes without downtime. - Bottlenecks: It manages massive traffic by spreading data loads automatically. Simple Scenario: In a user profile system, 'User 1' might only have a name, but 'User 2' has a name, bio, and five social media links. NoSQL stores both in the same collection without needing empty columns for 'User 1'.

What is SQL? SQL (Structured Query Language) is the standard language used to communicate with relational databases. It allows you to define, manage, and manipulate data stored in structured tables. How it works: • You write a "query" (a command) using specific keywords. • The Database Management System (DBMS) receives this query and parses it. • The engine locates the specific tables and rows requested. • It performs the action (like fetching or updating) and returns the result to you. Problem it solves: Manually searching through raw data files is slow and prone to errors. SQL solves this by providing a fast, consistent way to filter, sort, and retrieve specific data points from millions of records in seconds. Simple Scenario: If you have a table with millions of entries and you only need the "Email" of a user whose "ID" is 505, you use a SELECT command with a WHERE filter. The database skips everything else and gives you just that one piece of data.