ByteByteGo

Hub, Switch, & Router Explained

Every home and office network relies on these three devices, hub, switch, and router, yet their roles are often mixed up.

- A hub operates at Layer 1 (Physical Layer). It’s the simplest of the three, it doesn’t understand addresses or data types. When a packet arrives, it simply broadcasts it to every connected device, creating one big collision domain. That means all devices compete for the same bandwidth, making hubs inefficient in modern networks.

- A switch works at Layer 2 (Data Link Layer). It learns MAC addresses and forwards frames only to the correct destination device. Each port on a switch acts as its own collision domain, improving efficiency and speeding up communication within a LAN.

- A router operates at Layer 3 (Network Layer). It routes packets based on IP addresses and connects different networks together, for example, your home network to the Internet. Each router interface forms a separate broadcast domain, keeping local and external traffic isolated.

Understanding how these three layers work together is the foundation of every modern network, from your home Wi-Fi to the global Internet backbone.

Over to you: How do you usually figure out whether a network issue is caused by the router or the switch?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

14 hours ago | [YT] | 1,081

ByteByteGo

Why Is Nginx So Popular?

Apache dominated web servers for 20 years, then Nginx showed up and changed everything. Now Nginx powers some of the largest sites on the internet, including Netflix, Airbnb, Dropbox, and WordPress. com. Not because it's newer or trendier, but because it solves problems that Apache couldn't handle efficiently.

Here’s what makes Nginx so popular:

- High-Performance Web Server
- Reverse Proxy & Load Balancer
- Caching Layer
- SSL Termination (Offloading)

Over to you: What’s your primary use for Nginx today, web server, reverse proxy, or load balancer?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-li-posts

#systemdesign #coding #interviewtips
.

1 day ago | [YT] | 1,769

ByteByteGo

Network Debugging Commands Every Engineer Should Know

When someone says “It’s a network issue,” these commands help you find what’s wrong fast.

- ping: Checks if the destination responds and reports the round-trip time for basic reachability.
- traceroute / tracert: Shows each hop on the path so you can see where packets slow down or stop.
- mtr / pathping: Continuously measures latency and loss per hop to catch intermittent issues.
- ip addr, ip link / ipconfig /all: Prints local IPs, MACs, and interface status so you can verify the machine’s network identity.
- ip route: Reveals the routing table to confirm which gateway and next hop the system will use.
- ip neigh: Displays IP-to-MAC entries to detect duplicates or stale ARP records on the LAN.
- ss -tulpn: Lists listening sockets and PIDs so you can confirm a service is actually bound to the expected port.
- dig: Resolves DNS records to verify the exact IPs clients will connect to.
- curl -I: Fetches only HTTP(S) headers to check status codes, redirects, and cache settings.
- tcpdump / tshark: Captures packets so you can inspect real traffic and validate what’s sent and received.
- iperf3: Measures end-to-end throughput between two hosts to separate bandwidth limits from app issues.
- ssh: Opens a secure shell on the remote machine to run checks and apply fixes directly.
- sftp: Transfers files securely so you can pull logs or push artifacts during an incident.
- nmap: Scans open ports and probes versions to confirm which services are exposed and responding.

Over to you: What's your go-to command when debugging network issues?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

2 days ago | [YT] | 2,572

ByteByteGo

Evolution of HTTP

The Hypertext Transfer Protocol (HTTP) has evolved over the years to meet the needs of modern applications, from simple text delivery to high-performance, real-time experiences.

Here is how HTTP has progressed:
- HTTP/0.9: Built to fetch simple HTML documents with a single GET request.
- HTTP/1.0: Added headers and status codes to support richer interactions, but every request still required a new connection.
- HTTP/1.1: Introduced persistent connections and more methods, making the web faster and more efficient for everyday browsing.
- HTTP/2: Solved performance bottlenecks with multiplexing, enabling multiple requests to share one connection.
- HTTP/3 (QUIC): Shifted to UDP with QUIC to reduce latency and improve reliability, especially for mobile and real-time apps.

Over to you: Are you already taking advantage of HTTP/3 in your projects?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

3 days ago | [YT] | 2,106

ByteByteGo

System Performance Metrics Every Engineer Should Know

Your API is slow. But how slow, exactly? You need numbers. Real metrics that tell you what's actually broken and where to fix it.

Here are the four core metrics every engineer should know when analyzing system performance:

- Queries Per Second (QPS): How many incoming requests your system handles per second. Your server gets 1,000 requests in one second? That's 1,000 QPS. Sounds straightforward until you realize most systems can't sustain their peak QPS for long without things starting to break.

- Transactions Per Second (TPS): How many completed transactions your system processes per second. A transaction includes the full round trip, i.e., the request goes out, hits the database, and comes back with a response.

TPS tells you about actual work completed, not just requests received. This is what your business cares about.

- Concurrency: How many simultaneous active requests your system is handling at any given moment. You could have 100 requests per second, but if each takes 5 seconds to complete, you're actually handling 500 concurrent requests at once.

High concurrency means you need more resources, better connection pooling, and smarter thread management.

- Response Time (RT): The elapsed time from when a request starts until the response is received. Measured at both the client level and server level.

A simple relationship ties them all together: QPS = Concurrency ÷ Average Response Time

More concurrency or lower response time = higher throughput.

Over to you: When you analyze performance, which metric do you look at first, QPS, TPS, or Response Time?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

4 days ago | [YT] | 2,111

ByteByteGo

How DNS Works

You type a domain name and hit enter, but what actually happens before that webpage loads is more complex than most people realize. DNS is the phonebook of the internet, and every request you make triggers a chain of lookups across multiple servers.

Step 1: Someone types bytebytego.com into their browser and presses enter.

Step 2: Before doing anything, the browser looks for a cached IP address. Operating system cache gets checked too.

Step 3: Cache miss triggers a DNS query. The browser sends a query to the configured DNS resolver, usually provided by your ISP or a service like Google DNS or Cloudflare.

Step 4: Resolver checks its own cache.

Step 5-6: If the resolver doesn't have the answer cached, it asks the root servers, “Where can I find .com?” For bytebytego.com, the root server responds with the address of the .com TLD name server.

Step 7-8: Resolver queries the .com TLD server. TLD server returns the authoritative server address.

Step 9-10: This server has the actual A/AAAA record mapping the domain to an IP address. The resolver finally gets the answer: 172.67.21.11 for bytebytego. com.

Step 11-12: The IP gets cached at the resolver level for future lookups, and returned to the browser.

Step 13-14: The browser stores this for its own future use, and uses the IP to make the actual HTTP request.

Step 15: The web server returns the requested content.

All this happens in milliseconds, before your first page even starts loading.

Over to you: Which DNS tools or commands do you rely on most, dig, nslookup, or something else?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

1 week ago | [YT] | 3,881

ByteByteGo

Apache Kafka vs. RabbitMQ

Kafka and RabbitMQ both handle messages, but they solve fundamentally different problems. Understanding the difference matters when designing distributed systems.

Kafka is a distributed log. Producers append messages to partitions. Those messages stick around based on retention policy, not because someone consumed them. Consumers pull messages at their own pace using offsets. You can rewind, replay, reprocess everything. It is designed for high throughput event streaming where multiple consumers need the same data independently.

RabbitMQ is a message broker. Producers publish messages to exchanges. Those exchanges route to queues based on binding keys and patterns (direct, topic, fanout). Messages get pushed to consumers and then deleted once acknowledged. It is built for task distribution and traditional messaging workflows.

The common mistake is using Kafka like a queue or RabbitMQ like an event log. They're different tools built for different use cases.

Over to you: If you had to explain when NOT to use Kafka, what would you say?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

1 week ago | [YT] | 2,284

ByteByteGo

The HTTP Mindmap

HTTP has evolved from HTTP/1.1 to HTTP/2, and now HTTP/3, which uses the QUIC protocol over UDP for improved performance. Today, it’s the backbone of almost everything on the internet, from browsers and APIs to streaming, cloud, and AI systems.

At the foundation, we have underlying protocols. TCP/IP for IPv4 and IPv6 traffic. Unix domain sockets for local communication. HTTP/3 running over UDP instead of TCP. These handle the actual data transport before HTTP even comes into play.

Security wraps around everything. HTTPS isn't optional anymore. WebSockets power real-time connections. Web servers manage workloads. CDNs distribute content globally. DNS resolves everything to IPs. Proxies (forward, reverse, and API gateways) route, filter, and secure traffic in between.

Web services exchange data in different formats, REST with JSON, SOAP for enterprise systems, RPC for direct calls, and GraphQL for flexible queries. Crawlers and bots index the web, guided by robots.txt files that set the boundaries.

The network world connects everything. LANs, WANs, and protocols like FTP for file transfers, IMAP/POP3 for email, and BitTorrent for peer-to-peer communication. For observability, packet capture tools like Wireshark, tcpdump, and OpenTelemetry let developers peek under the hood to understand performance, latency, and behavior across the stack.

Over to you: HTTP has been evolving for 30+ years, what do you think the next big shift will be?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

1 week ago | [YT] | 2,524

ByteByteGo

Database Types You Should Know in 2025

There’s no such thing as a one-size-fits-all database anymore. Modern applications rely on multiple database types, from real-time analytics to vector search for AI. Knowing which type to use can make or break your system’s performance.

Relational: Traditional row-and-column databases, great for structured data and transactions.

Columnar: Optimized for analytics, storing data by columns for fast aggregations.

Key-Value: Stores data as simple key–value pairs, enabling fast lookups.

In-memory: Stores data in RAM for ultra-low latency lookups, ideal for caching or session management.

Wide-Column: Handles massive amounts of semi-structured data across distributed nodes.

Time-series: Specialized for metrics, logs, and sensor data with time as a primary dimension.

Immutable Ledger: Ensures tamper-proof, cryptographically verifiable transaction logs.

Graph: Models complex relationships, perfect for social networks and fraud detection

Document: Flexible JSON-like storage, great for modern apps with evolving schemas.

Geospatial: Manages location-aware data such as maps, routes, and spatial queries.

Text-search: Full-text indexing and search with ranking, filters, and analytics.

Blob: Stores unstructured objects like images, videos, and files.

Vector: Powers AI/ML apps by enabling similarity search across embeddings.

Over to you: Which database type do you think will grow fastest in the next 5 years?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

1 week ago | [YT] | 2,483

ByteByteGo

Can a web server provide real-time updates?

An HTTP server cannot automatically initiate a connection to a browser. As a result, the web browser is the initiator. What should we do next to get real-time updates from the HTTP server?

Both the web browser and the HTTP server could be responsible for this task.

🔹Web browsers do the heavy lifting: short polling or long polling. With short polling, the browser will retry until it gets the latest data. With long polling, the HTTP server doesn’t return results until new data has arrived.
🔹HTTP server and web browser cooperate: WebSocket or SSE (server-sent event). In both cases, the HTTP server could directly send the latest data to the browser after the connection is established. The difference is that SSE is uni-directional, so the browser cannot send a new request to the server, while WebSocket is fully-duplex, so the browser can keep sending new requests.

Over to you: of the four solutions (long polling, short polling, SSE, WebSocket), which ones are commonly used, and for what use cases?

--
We just launched the all-in-one tech interview prep platform, covering coding, system design, OOD, and machine learning.

Launch sale: 50% off. Check it out: bit.ly/bbg-yt

#systemdesign #coding #interviewtips
.

1 week ago | [YT] | 1,589