Architect’s Guide: Backend Architecture, Microservices, Service Mesh, and Message Queues

Overview – The author presents a “architect roadmap” that reflects personal experience in backend design, emphasizing that architecture is a series of decisions constrained by team expertise, cost, resources, schedule, and business stage.

Microservices – Defined as a style of building small, single‑responsibility services communicating via language‑agnostic APIs. The section discusses Conway’s Law, the importance of domain‑driven design (DDD) and lists DDD implementation steps.

Gateway – Differentiates access gateways (domain/DNS, load‑balancing, SSL, IPv6) from business gateways (authentication, rate‑limiting, circuit‑breaker, retry, plugin, BFF) and mentions popular open‑source implementations such as Kong, APISIX, Spring Cloud Gateway, gRPC‑Gateway, Kratos, go‑zero.

Protocol Selection – Compares HTTP REST and RPC (Dubbo, Motan, Thrift, gRPC), outlining their strengths in API definition, transmission efficiency, and fault tolerance.

Service Registration & Discovery – Explains server‑side (DNS + load balancer) vs client‑side (etcd, ZooKeeper, Consul) models, with pros and cons of each approach.

Configuration Center – Reviews etcd/ZooKeeper/Consul, Kubernetes ConfigMap/Secret, and higher‑level solutions like Nacos and Apollo.

Observability – Covers the three pillars: tracing (OpenTracing, Jaeger, Zipkin, SkyWalking, OpenTelemetry), logging (RFC 5424 levels, collection pipelines), and metrics (Prometheus, Zabbix, counter/gauge/histogram/summary types).

Service Mesh – Describes the sidecar‑based mesh architecture, its role in handling service‑to‑service communication, and lists popular implementations (Istio, Linkerd, Conduit) with notes on high‑availability considerations.

Message Queues – Defines MQ concepts, key selection criteria (HA, throughput, features, broadcast, backlog, persistence, duplicate consumption, ordering) and compares Redis, RabbitMQ, Kafka, RocketMQ, and Pulsar, highlighting each system’s strengths and trade‑offs.

Tracing Diagram

[Span A]  ←←←(the root span)
        |
 +------+------+
 |          |
[Span B]      [Span C] ←←←(Span C is a child of Span A, ChildOf)
 |          |
[Span D]      +---+-------+
           |           |
       [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                   ↑
                                   ↑
                                   ↑
                         (Span G is called after Span F, FollowsFrom)

The article concludes with references and a brief author note, reinforcing that architecture is a decision‑making process guided by constraints and continuous learning.