Backend Interview Essentials: TCP/UDP, HTTP, Linux, MySQL Indexes, C++ STL & Concurrency

TCP vs UDP

TCP is connection‑oriented, provides reliable ordered delivery, implements congestion and flow control, and has a larger header (minimum 20 bytes).

UDP is connectionless, offers low‑latency best‑effort delivery, has no congestion or flow control, and uses a fixed 8‑byte header.

Transport protocol used by HTTP

HTTP/1.1 and HTTP/2 are built on TCP because they require reliable, ordered transmission of web resources. HTTP/3 uses QUIC over UDP to eliminate TCP’s head‑of‑line blocking and to reduce connection‑setup latency.

HTTP status‑code classes

1xx : Informational responses.

2xx : Successful requests (e.g., 200).

3xx : Redirection (e.g., 301, 302).

4xx : Client errors (e.g., 404, 405).

5xx : Server errors (e.g., 500).

Short vs long HTTP connections

Traditional short connections create a new TCP handshake for each request. HTTP Keep‑Alive (long connection) reuses the same TCP socket for multiple requests, reducing latency. Since HTTP/1.1 the default is to keep the connection alive unless explicitly closed.

Linux process inspection commands

ps

: List current processes. ps -aux: Show user, CPU, and memory usage for each process. ps -elf: Display detailed process hierarchy, priority, and flags.

MySQL index implementation (B+Tree)

InnoDB stores indexes as B+Trees. Internal nodes contain only keys, while leaf nodes store row pointers and are linked via a doubly‑linked list, enabling efficient range queries. SELECT * FROM product WHERE id = 5; The query traverses the B+Tree from root to leaf, typically requiring 3–4 disk I/O operations even for tables with millions of rows.

Why B+Tree instead of B‑Tree?

Internal nodes store only keys, allowing a higher fan‑out and a shallower tree, which reduces I/O.

All data resides in leaf nodes that are linked, making sequential scans and range queries fast.

In pure‑memory scenarios B‑Tree may have a slight random‑access advantage, but B+Tree still excels for range queries and large on‑disk datasets.

C++ struct vs class

Default member access: struct members are public , class members are private .

Default inheritance: struct inherits public , class inherits private .

struct A { int x; void f() {} };
class B { int y; void g() {} };
int main(){
    A a; a.x = 10; a.f();
    B b; // b.y = 20; // error: private member
    // b.g(); // error: private member
    return 0;
}

C++ STL containers overview

Containers are grouped into three families:

Sequence containers : vector, deque, list, array – store elements in insertion order.

Associative containers (ordered): set, multiset, map, multimap – typically implemented with red‑black trees.

Unordered associative containers : unordered_set, unordered_multiset, unordered_map, unordered_multimap – hash‑table based.

Container adapters : stack, queue, priority_queue – provide restricted interfaces built on other containers.

Thread safety of std::map

std::map

is not thread‑safe. Concurrent writes or read‑write operations can corrupt its underlying red‑black tree. Synchronization must be added externally, e.g., using std::mutex and std::lock_guard, or by using a thread‑safe container library.

#include <map>
#include <mutex>

std::map<int,int> my_map;
std::mutex mtx;

void safe_insert(int key, int value){
    std::lock_guard<std::mutex> lock(mtx);
    my_map[key] = value;
}

int safe_find(int key){
    std::lock_guard<std::mutex> lock(mtx);
    auto it = my_map.find(key);
    return (it != my_map.end()) ? it->second : -1;
}

Queue vs stack

Queue follows FIFO order; suitable for task scheduling.

Stack follows LIFO order; suitable for call‑stack management.