Zhuifeng Notes

Dubbo Architecture and Core Concepts

Tue, 25 Aug 2026 00:00:00 +0000

Dubbo’s core strength lies in its clear separation of responsibilities and its highly pluggable extension mechanism. Understanding the layering and the Invoker abstraction is the foundation for reading Dubbo’s source code and troubleshooting production issues.

Layered Architecture

From top to bottom Dubbo is divided into logical layers, each depending only on the interface (not the implementation) of the layer below:

service / config layer: the user-facing API and configuration layer, where @DubboService, @DubboReference, ReferenceConfig and ServiceConfig live.
proxy layer: generates dynamic proxies for service interfaces so remote calls are transparent to business code.
registry layer: encapsulates service registration and subscription, sensing provider/consumer up and down events.
cluster layer: wraps multiple Invokers into a “cluster Invoker”, responsible for load balancing, fault tolerance and routing.
protocol layer: encapsulates the RPC call; the core of Invoker export and reference.
filter chain: interceptors across the call path, usable for logging, auth, rate limiting and other cross-cutting concerns.

Invoker and SPI

Invoker is Dubbo’s universal domain model, representing “an executable and describable call”, abstracting local, remote and cluster invocations. URL acts as the configuration bus running through every layer; almost every extension point passes parameters via URL.

Kafka Storage and Consumption Model

Tue, 25 Aug 2026 00:00:00 +0000

Kafka’s high performance relies on “partitioned log + sequential writes + batched pulls”. Understanding the storage and consumption model is essential to configure parallelism correctly and avoid duplicate consumption.

Topics and Partitions

A topic is a logical subject; a partition is the physical unit of parallelism, and messages are only appended to the end of a partition.
Each partition is an ordered, immutable log composed of multiple segment files, maintaining an offset (unique and monotonically increasing within the partition).
The partition count determines the upper bound of consumption parallelism: at any moment a partition is consumed by exactly one consumer within a group.

Offset and Consumption Position

The position a consumer commits after processing messages is the offset, which Kafka stores in the internal topic __consumer_offsets:

MySQL Indexing Internals and Best Practices

Tue, 25 Aug 2026 00:00:00 +0000

Indexes are the decisive factor for MySQL query performance. Understanding InnoDB’s B+Tree index structure is the only way to write SQL that truly hits indexes.

B+Tree and the Clustered Index

InnoDB organizes indexes with a B+Tree whose non-leaf nodes only store index keys for navigation, while all data lives in leaf nodes that are linked in a doubly-linked list, which is ideal for range scans.

Redis Data Structures and Underlying Implementation

Tue, 25 Aug 2026 00:00:00 +0000

Redis exposes five common types to users, but underneath there are multiple encodings (encoding). Automatically switching encodings based on data size is the key to balancing memory and performance.

Core Underlying Structures

SDS (Simple Dynamic String): records length and pre-allocates space compared to C strings, avoiding buffer overflow and supporting binary safety.
ziplist / listpack: compact contiguous-memory lists that save space and suit small data volumes.
linkedlist: a doubly-linked list that replaces ziplist when there are many elements.
dict (dictionary): a hash table using chaining for collisions, with progressive rehash to avoid blocking.
skiplist (skip list): a multi-level ordered linked list, combined with dict to implement zset for efficient range queries.

Encodings and Conversions per Type

Type	Small-data encoding	Large-data encoding	Conversion threshold (illustrative)
string	int / embstr	raw	length > 44 bytes becomes raw
hash	ziplist/listpack	hashtable	element count or single value exceeds threshold
list	quicklist (ziplist segments)	quicklist	—
set	intset	hashtable	contains non-integers or too many elements
zset	ziplist	skiplist+dict	element count or value length exceeds threshold

Taking zset as an example, small data uses a compact ziplist (member and score adjacent); when the element count or a single member length exceeds the threshold it converts to skiplist + dict, ensuring ordered traversal and member lookup are O(1)/O(log n).

ZooKeeper Data Model and the ZAB Protocol

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper’s reliability comes from its simple data model and the strongly-consistent ZAB protocol. Understanding both is a prerequisite for using ZK correctly.

The znode Data Model

ZK maintains a hierarchical tree similar to a file system; each node is a znode that can hold both data and children. Its type determines lifecycle and concurrency semantics:

Persistent / Ephemeral: ephemeral nodes are auto-deleted when the session disconnects, forming the basis of distributed locks and leader election.
Plain / Sequential: sequential nodes get a monotonically increasing sequence number appended on creation.
Each znode carries version, cversion, aversion; versions increment on modification, providing optimistic-lock semantics.

Session and Watcher

A client establishes a session with the server, kept alive via heartbeats. On session timeout the server cleans up its ephemeral nodes. A client can register a Watcher on a node and receives a one-time notification when the node changes (data write, children change); it must re-register to keep watching.

PageFly

Mon, 01 Jan 0001 00:00:00 +0000

PageFly is a lightweight publishing surface for AI workflows: write HTML or Markdown and ship it. Good for analysis pages, tool pages, and quick experiments.

Status: Live
URL: https://fly.882680.xyz
Stack: Cloudflare Pages + Functions + KV (free tier)
Use cases: personal workflow landing pages, light product prototypes, AI output showcases

Distributed Coordination in Practice

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper offers primitive-level coordination; almost every distributed coordination need can be built from the combination of “ephemeral node + sequential node + Watcher”.

Leader Election

Each candidate creates an ephemeral sequential node under /election; the one with the smallest sequence becomes Master. Non-smallest nodes watch their predecessor; when the predecessor disappears they re-evaluate whether they are now smallest, achieving automatic failover:

/election
 ├── /n_0000000001 (master)
 ├── /n_0000000002 (watches 001)
 └── /n_0000000003 (watches 002)

Configuration Center

Write configuration into a persistent node; clients read it and register a Watcher. On configuration change the client receives a notification and hot-reloads without restarting the app. Keep config nodes small to avoid oversized single pushes.

Kafka Reliability and Exactly-Once

Tue, 25 Aug 2026 00:00:00 +0000

Kafka’s reliability requires coordinated configuration across the producer, broker and consumer. We cover it through three goals: no loss, no duplication, ordered.

Producer-Side Reliability

Control write durability level via acks:

acks=0: considered successful as soon as sent; may lose messages; highest throughput.
acks=1: success once the leader writes; may lose if the leader crashes.
acks=all: success only after all ISR replicas sync; safest, combined with min.insync.replicas to avoid single points.

Enabling retries (retries) handles transient failures but introduces duplicates: network jitter causes the producer to retry without receiving the ack, writing the same message twice.

Redis Cache Design

Tue, 25 Aug 2026 00:00:00 +0000

Introducing a cache dramatically reduces database pressure, but poor design introduces the classic problems of penetration, breakdown and avalanche. We break down the causes and countermeasures below.

The Three Classic Problems

Cache penetration: querying data that does not exist, so neither cache nor DB returns it and every request hits the DB. Mitigate with caching empty values (short TTL) or a Bloom filter to block illegal keys.
Cache breakdown: the moment a hot key expires, many concurrent requests all fall back to the DB at once. Mitigate with a mutex (only one thread rebuilds), logical expiration (async refresh), or never-expire hot keys.
Cache avalanche: a large number of keys expire simultaneously, or Redis becomes entirely unavailable, overwhelming the DB. Mitigate with random jitter on expiration times, multi-level caching, and Redis high availability (Sentinel/Cluster).

Cache-Aside and Consistency

The most common pattern is Cache-Aside (旁路缓存):

Service Registration and Discovery in Practice

Tue, 25 Aug 2026 00:00:00 +0000

Service registration and discovery are the foundation of microservice architecture. Dubbo abstracts the registry as the Registry interface, so you can switch smoothly between ZooKeeper, Nacos, Consul and others without changing business code.

Connecting a Registry

Using Nacos as an example, you only need to declare the registry address and protocol in configuration. On startup Dubbo automatically exports (export) and subscribes (subscribe) services:

dubbo:
 application:
 name: order-service
 registry:
 address: nacos://127.0.0.1:8848
 protocol:
 name: dubbo
 port: 20880

After a provider starts, it writes its metadata (interface, IP, port, weight, etc.) into the registry. When a consumer starts, it subscribes to the interface node, fetches the available provider list and caches it locally; subsequent calls go directly to the local cache, reducing registry pressure.

Transactions and Locking

Tue, 25 Aug 2026 00:00:00 +0000

Under concurrency, transactions and locks together guarantee data consistency. InnoDB balances performance and isolation through the coordination of MVCC and locking.

ACID and Isolation Levels

A transaction’s ACID is guaranteed by different mechanisms: atomicity by undo log, durability by redo log, isolation by MVCC and locks, and consistency is the ultimate goal.

The SQL standard defines four isolation levels; InnoDB defaults to REPEATABLE READ:

READ UNCOMMITTED: possible dirty reads
READ COMMITTED: avoids dirty reads, possible non-repeatable reads
REPEATABLE READ: avoids non-repeatable reads (InnoDB additionally avoids phantom reads)
SERIALIZABLE: fully serial, lowest performance

MVCC and Logs

MVCC (Multi-Version Concurrency Control) lets reads avoid locks and reads/writes not block each other. Each row implicitly carries trx_id and roll_pointer, builds historical versions via undo log, and uses a ReadView to decide whether a version is visible to the current transaction.

Investment Advisor System

Mon, 01 Jan 0001 00:00:00 +0000

A personal investment research prototype: fetch A-share and fund data via AKShare, persist in Supabase, and use the All-Weather strategy as an asset allocation reference.

Status: In progress
Stack: Python / AKShare / Supabase / All-Weather
Goal: wire up “data → backtest → portfolio tracking” into a reusable workflow
Scope: Personal research only; not investment advice

Cognition Matching / AI Cognitive Profile

Mon, 01 Jan 0001 00:00:00 +0000

A light-asset startup exploration: structure a person’s knowledge, preferences, and capabilities into an AI cognitive profile, then match them with opportunities (projects, people, content).

Status: Planning
Form: React + Claude API lightweight prototype
Commitment: ~18–27 hours per week, free/low-cost options preferred
Core question: How to turn “cognitive similarity” into a computable, explainable matching signal

Chinese AI Humanizer Skill

Mon, 01 Jan 0001 00:00:00 +0000

A WorkBuddy skill (v3.0.0-zh) that strips AI-generated flavor from Chinese text. Covers 18 categories: exaggerated symbolism, promotional language, shallow -ing analysis, vague attribution, dash overuse, rule-of-three paragraphs, AI vocabulary, and more.

Version: v3.0.0-zh
Form: WorkBuddy skill
Use cases: WeChat articles, technical docs, emails, reports — anywhere Chinese should sound human
Approach: detect tell patterns first, then rewrite by category

Banking Ontology

Mon, 01 Jan 0001 00:00:00 +0000

Structuring recurring banking concepts — organization, products, accounts, transactions, customers, channels, risk, regulatory reporting — into an ontology that becomes a reusable knowledge framework.

Status: Research
Outputs: slide deck, concept diagrams, domain glossary
Goal: a shared language for mapping business → technology → data
Related areas: ECIF, MDM, regulatory reporting, data assets

First post — why "Zhuifeng Notes"

Sat, 15 Aug 2026 00:00:00 +0000

After years of building banking system architecture, most of what I’ve learned — the pitfalls, the hard-won insights — lived scattered across notes and chat logs. This site is where I organize them.

What I’ll write

Architecture: ECIF, core banking, distributed architecture, and how Domain-Driven Design (DDD) lands in banking.
Banking: payment clearing, interest and limits, accounts/cards, AML/KYC/CRS.
Data: data governance, encryption and security, sharding, messaging and stream processing.

Who it’s for

Peers, engineers moving into fintech, and anyone curious about why banking systems are designed the way they are.

Applying DDD Aggregates in a Banking ECIF

Wed, 12 Aug 2026 00:00:00 +0000

In an ECIF, the concept of “customer” is huge: retail, corporate, and interbank clients each have different attributes, relationships, and lifecycles. Forcing them into one giant Customer entity makes the code rot fast.

Slice by bounded context

Split the customer across bounded contexts:

Party (master data): unified natural-person / institution identity and base attributes.
Profile: risk appetite, marketing tags — high read/write churn.
Relationship: shareholding, guarantee, and group relationships.

Where the aggregate root goes

Each context defines its own aggregate root. In Party, Party is the root; Address and Contact are value objects, keeping cross-aggregate calls out of the consistency boundary.

ECIF in one read — why customer data must be centralized

Mon, 10 Aug 2026 00:00:00 +0000

Before ECIF, branches, internet banking, and the card center each kept their own customer records. The same person appeared with different names, IDs, and contacts across systems — making both marketing and risk control impossible.

What ECIF solves

ECIF (Enterprise Customer Information Facility) consolidates customer master data scattered across business systems into one place, exposing a single customer view.

Unique identity: a Party ID unifies natural persons / institutions, not the ID number.
Primary/secondary: supports one person many accounts, one account many cards, with unique master data.
Service-oriented: other systems query via interfaces instead of keeping their own copies.

Key technical trade-offs

Read/write split: master writes are strongly consistent; queries can hit cache / read replicas.
Auditable changes: customer changes are traced to satisfy regulatory audits.

ECIF is not “yet another database” — it is the bedrock of bank digitalization.

Bank Data Governance — metadata before quality

Sat, 08 Aug 2026 00:00:00 +0000

Many bank data-governance programs degenerate into “fill in the metadata, assign owners.” To get results, governance must be built into the data production pipeline.

Do two things first

Metadata & lineage: where a field comes from, which jobs transform it, where it flows — must be tracked automatically.
Quality rules built-in: non-null, uniqueness, consistent definitions act as ETL/lakehouse gates; bad data never lands.

Security & encryption

Encryption at rest: sensitive fields (ID numbers, card numbers) encrypted on disk.
Dynamic masking: query-side masking by role; dev environments never see plaintext.

The goal of governance isn’t a pretty report — it’s giving downstream systems confidence to use the data.

About

Mon, 01 Jan 0001 00:00:00 +0000

Bio

Wang Peng. BSc in Mathematics, MSc in Computer Science (a cross-discipline transition), currently a backend engineer at a bank’s headquarters (Beijing), working on core banking systems. Main interests: distributed architecture, unitized deployment, core banking domain modeling, and the engineering adoption of AI in banking.

Credentials: PMP
Tech focus: Java backend, distributed systems, DDD / CQRS / Saga, enterprise architecture, data assets
Current focus: building a customer-facing AI Agent platform; evaluating enterprise Java AI frameworks (Spring AI 2.0 / LangChain4j / SAA / Embabel)

Experience

Stage	Detail
Education	BSc Mathematics → MSc Computer Science (cross-discipline)
Current	Core banking systems engineer at a bank HQ
Exam	Preparing for the senior «System Architect» certification

Tech Stack

Java · Spring Cloud · distributed transactions · unitization · DDD · databases (MySQL / sharding) · messaging & streams (Kafka) · caching (Redis) · coordination (ZooKeeper) · microservice governance · enterprise architecture