Common Pitfalls and Core Concepts of Distributed Systems, Message Queues, Caching, Sharding, and Transactions
This article provides a comprehensive overview of distributed system fundamentals—including CAP and BASE theories—while detailing typical pitfalls and mitigation strategies for message queues, distributed caches, database sharding, and distributed transactions, helping engineers decide when and how to adopt distributed architectures.
Overview
The article introduces distributed systems using a Naruto analogy, defining them as a set of independent computers that cooperate to appear as a single service and highlighting their advantages and drawbacks.
CAP and BASE Theories
It explains the CAP theorem (Consistency, Availability, Partition tolerance) and the BASE model (Basically Available, Soft state, Eventually consistent), showing how real‑world systems trade off these properties.
Message Queue Pitfalls
Key issues such as non‑idempotence, message loss, out‑of‑order delivery, backlog, expiration, and queue saturation are discussed for RabbitMQ and Kafka . Mitigation strategies include using transaction or confirm modes, designing idempotent consumers, persisting messages (setting deliveryMode=2 ), configuring replication factors, and managing consumer ACKs.
Distributed Cache Pitfalls
The article examines Redis high‑availability via the sentinel mechanism, describing failure scenarios (master crash, asynchronous replication, split‑brain) that can cause data loss and recommending configuration of min‑slaves‑to‑write and min‑slaves‑max‑lag to reduce risk.
Sharding (Database Partitioning) Pitfalls
It distinguishes vertical and horizontal splitting, outlines challenges such as cross‑shard queries and transaction consistency, and reviews unique ID generation methods—auto‑increment, UUID , timestamp‑based IDs, Snowflake , Baidu UIDGenerator , and Meituan Leaf‑Snowflake —highlighting their trade‑offs.
Distributed Transaction Pitfalls
Various approaches are covered: XA two‑phase commit, TCC (try‑confirm‑cancel), SAGA, reliable message (prepared/commit) and max‑effort notification. For each, the principle, suitable scenarios, advantages, and drawbacks are summarized.
Finally, the article advises that adopting distributed architecture should be based on business needs, team capability, and cost considerations, and promises further deep‑dive posts on underlying principles and best practices.
Wukong Talks Architecture
Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.