Comprehensive Guide to Backend Architecture: Microservices, Observability, Service Mesh, and Messaging

Overview

The "Architect’s Map" is a large‑scale concept that reflects how an architect evolves from points to planes to a complete graph; this article focuses on the backend side, summarizing technology stacks, design ideas, and suitable scenarios for cloud‑native and open‑source solutions.

It is divided into three parts: the first part concentrates on microservices and common message queues, the second on databases, distributed consistency/locks/caching/task scheduling, and streaming, and the third on DevOps, project management, and team building.

Microservices

Microservices are a software architecture style that builds applications from small, single‑responsibility building blocks communicating via language‑agnostic APIs. Compared with monolithic architecture, services can be developed, deployed, and scaled independently, reducing change scope and risk.

Theoretical Foundations

Conway’s Law states that system designs mirror the communication structures of the organizations that build them. Effective architecture therefore requires aligning team communication with system boundaries.

Domain‑Driven Design (DDD)

DDD helps model complex domains by defining bounded contexts, entities, value objects, aggregates, and repositories, providing a solid foundation for microservice decomposition.

Gateway

Gateways serve as the unified entry point for microservices, handling traffic ingress, security, routing, authentication, rate limiting, circuit breaking, and service aggregation. Two types are discussed:

Access gateway – provides basic traffic entry and global security.

Business gateway – implements BFF, routing, authentication, rate limiting, circuit breaking, and plugin capabilities (e.g., Kong, APISIX, Spring Cloud Gateway, gRPC‑Gateway).

Protocol

Service communication can use HTTP REST (API design style) or RPC (point‑to‑point calls). REST is simple and widely supported, while RPC (e.g., Dubbo, Motan, Thrift, gRPC) offers stronger typing, higher efficiency, and better fault tolerance.

Service Registration & Discovery

Two modes are described:

Server‑side mode – uses load balancers and DNS for registration and discovery.

Client‑side mode – relies on a registration center (e.g., etcd, ZooKeeper, Consul) with client‑side load balancing.

Configuration Center

Configuration centers store KV data, service registration info, and runtime configuration. Examples include etcd, ZooKeeper, Consul, Kubernetes ConfigMap/Secret, Nacos, and Apollo.

Observability

Observability consists of tracing, logging, and metrics. In cloud‑native environments, tracing (e.g., Jaeger, Zipkin, SkyWalking) helps reconstruct call graphs; logging captures business and system events; metrics (e.g., Prometheus counters, gauges, histograms) monitor resource and business health.

Tracing Example

[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 follows Span F, FollowsFrom)

Service Mesh

Service mesh abstracts service‑to‑service communication, providing discovery, traffic control, security, and observability via sidecar proxies. Popular implementations include Istio (Envoy sidecar), Linkerd, Conduit, and Apache Pulsar’s lightweight mesh.

Message Queue

Message queues enable asynchronous communication, load leveling, and eventual consistency. The article compares Redis, RabbitMQ, Kafka, RocketMQ, and Pulsar across HA, throughput, feature richness, persistence, duplicate consumption, and ordering.

Key Comparison

Redis – simple, in‑memory, limited persistence and ordering.

RabbitMQ – supports priority, TTL, dead‑letter queues.

Kafka – high‑throughput, partitioned log, strong ordering per partition.

RocketMQ – combines features of RabbitMQ and Kafka, supports transactional messages.

Pulsar – separates compute and storage, offers multi‑consumer models and strong HA.

Conclusion

The article emphasizes that achieving high performance and high availability inevitably adds complexity; choosing the right stack requires balancing features, operational cost, and team expertise.