Technical Architecture Overview of an Internet Company: DNS, Load Balancing, API Gateway, Microservices, and Push Systems

Overall Architecture

APP, PC and third‑party callers obtain the load‑balancer IP through the traditional LocalDNS service, while APPs can use HttpDNS for more real‑time and precise domain resolution.

Requests reach a unified access layer via the load balancer; this layer maintains long connections.

The API gateway serves as the entry point for microservices, handling protocol conversion, request routing, authentication, traffic control, and data caching.

Business servers use a PUSH system to deliver real‑time messages such as IM and notifications.

Business servers communicate with each other via a proprietary RPC protocol and access external third‑party services through a NAT gateway.

Domain Resolution

Traditional DNS

DNS (Domain Name System) is a distributed directory service that maps domain names to IP addresses, allowing users to access resources without remembering numeric IPs.

The resolution process involves:

Client recursively queries the LocalDNS (usually the ISP’s edge DNS) to obtain an IP.

LocalDNS performs iterative queries to retrieve the IP by contacting successive authoritative name servers.

HttpDNS

HttpDNS sends domain‑resolution requests over HTTP, bypassing the ISP’s LocalDNS to avoid hijacking and cross‑network issues, improving reliability for mobile internet services.

Compared with traditional LocalDNS, Tencent Cloud HttpDNS offers the following advantages:

Advantage

Tencent Cloud HttpDNS

Operator LocalDNS

Speed

Coverage of top 17 domestic operators, Southeast Asia and North America; precise and fast resolution

Cross‑network access and resolution anomalies

Security

Avoids operator DNS hijacking and pollution

Results may be redirected to ads or third‑party pages

Intelligence

Accurately identifies request source and directs to optimal nodes

Simply forwards queries to other operators without recursion

Reliability

Three‑site IP cluster with automatic failover, SLA >99%

Inconsistent cache server maintenance, frequent failures

Load Balancing

To overcome single‑machine performance limits and single‑point failures, load balancing distributes traffic across multiple servers horizontally.

Clients first reach a load‑balancer, which uses scheduling algorithms to forward traffic to application servers and performs health checks to remove faulty nodes, ensuring high availability.

Load balancing can be hardware‑based (e.g., F5) or software‑based (e.g., LVS, NGINX, HAProxy) and operates at L4 (transport layer) or L7 (application layer).

L4 vs L7

L4 load balancing works at the transport layer, forwarding packets based on IP/TCP headers after the initial SYN handshake.

L7 load balancing operates at the application layer, acting as a proxy that terminates client connections, parses HTTP requests, and forwards them to selected backend servers.

LVS Forwarding Modes

LVS (IP Virtual Server) works below L4 and supports several forwarding modes:

DR mode (Direct Routing)

Rewrites the MAC address and sends the request to the real server, which replies directly to the client. Requires the scheduler and real servers to share a physical network segment and the real servers to configure a VIP.

NAT mode (Network Address Translation)

The scheduler rewrites the destination address, forwards the request to the real server, and rewrites the source address on the response before sending it back to the client, acting as a gateway.

TUNNEL mode

Requests are encapsulated in an IP tunnel to the real server; the real server replies directly to the client, so the scheduler only handles the inbound packets.

FULL NAT mode

Based on NAT, it also performs source NAT (SNAT) so that response traffic passes through the load balancer, allowing the balancer to remain a gateway; however, it loses the client’s original IP and has lower performance.

Scheduling Algorithms

Round Robin : Distributes requests sequentially across servers, ignoring current load.

Weighted Round Robin : Assigns higher probability to servers with larger weights, useful when server capacities differ.

Least Connections : Sends traffic to the server with the fewest active connections.

Hash : Uses a hash of a specified key modulo the number of servers to select a target.

Consistent Hash : Minimizes key remapping when nodes are added or removed, improving stability in distributed systems.

API Gateway

The API gateway is a server cluster that acts as the sole external entry point, encapsulating internal architecture and exposing REST/HTTP APIs while handling authentication, monitoring, load balancing, caching, and traffic control.

Core functions include full API lifecycle management (creation, maintenance, publishing, deprecation), multi‑environment testing, versioning, and rollback.

API configuration consists of front‑end settings (HTTP method, URL path, parameters) and back‑end settings (service name, parameters), enabling seamless translation from client requests to microservice calls.

Full Asynchronous Processing

By leveraging non‑blocking I/O and multiplexing, the gateway can handle massive concurrency with few threads, increasing throughput and reducing resource costs.

Common solutions include Tomcat/Jetty + NIO + Servlet 3.1 and Netty + NIO ; Spring 5’s WebFlux (built on Netty + NIO or Servlet 3.1 non‑blocking containers) is also recommended.

Chain Processing

Using a filter chain (responsibility‑chain pattern), the gateway provides routing, protocol conversion, caching, rate limiting, monitoring, and logging, with extensibility for custom business logic while avoiding time‑consuming operations.

Request Rate Limiting

Rate limiting protects the system from overload. Implementations can be cluster‑wide (using a shared cache like Redis) or single‑machine (in‑memory). Recommended algorithms are token‑bucket, leaky‑bucket, and simple counters.

Circuit Breaking and Degradation

When downstream services become unavailable or slow, upstream services stop calling them to preserve overall stability, returning fallback responses. This follows the circuit‑breaker pattern, with state transition diagrams illustrated in the accompanying image.

Service degradation reduces load on non‑critical services during high traffic, returning cached data or simplified responses. Degradation granularity can be at API, feature, or system level and requires prior SLA definition.

Business Isolation

To prevent cross‑impact between different business logics, isolation can be achieved via thread‑pool segregation or cluster segregation; for Java, cluster isolation is preferred due to thread overhead.

PUSH Notification System

The push system supports multiple channels (Apple, Huawei, Xiaomi, FCM, etc.) and provides both a quick‑push console and server‑side integration, enhancing user retention and experience.

Device connection, registration, and user binding process

Message push flow

Messages are persisted to handle offline users. When a business event occurs, the system attempts a push via third‑party channels or a self‑built TCP connection. If the client acknowledges receipt, the server updates the message status; otherwise, the message is retried on the next connection, with deduplication logic applied.

Microservice System

The diagram illustrates a typical microservice architecture with service discovery, load balancing, and inter‑service communication.

References

www.linuxvirtualserver.org/zh/lvs1.htm… www.infoq.cn/article/Mag… www.cnblogs.com/mindwind/p/… blog.csdn.net/gaopeiliang… www.jianshu.com/p/76cc8ba5c… www.jianshu.com/p/cda7c0366… juejin.im/post/684490…

More Recommendations

Product advanced capabilities: Architecture diagram design and drawing Architecture overview: Evolution, patterns, and core elements Microservice architecture design summary and practice Kafka detailed guide Large‑scale e‑commerce system architecture Microservice architecture – design summary