How Event Sourcing and a Go DSL Power a Scalable Points System

This article explains how a financial e‑commerce platform uses the Event Sourcing architecture pattern, an asynchronous message bus, and a Go‑based domain‑specific language to build a flexible, exactly‑once points system that decouples business rules from application code and simplifies operations.

GF Securities FinTech
GF Securities FinTech
GF Securities FinTech
How Event Sourcing and a Go DSL Power a Scalable Points System

Architecture Patterns and Event Sourcing

Architecture patterns are reusable solutions to common problems; applying them avoids reinventing the wheel. The article focuses on the Event Sourcing pattern, illustrated with a points (积分) system used in both e‑commerce and financial services.

Points System Use Cases

Points are widely used in e‑commerce (e.g., JD, Taobao) and in the securities e‑commerce platform of GF Securities. They drive customer loyalty, enable internal gamification, and can be converted into employee performance rewards.

Challenges of Tight Coupling

Initially the points service exposed simple add/subtract APIs, forcing each application to embed points‑rule logic. When rules changed, every client needed code updates, increasing maintenance cost.

Event‑Driven Decoupling via Message Bus

Applications now publish events to an asynchronous message bus (Kafka). The points service subscribes to these events, applies configurable rules, and records bookkeeping entries, achieving loose coupling and easier rule changes.

Exactly‑Once Processing

To guarantee that each points event is processed only once, the system adds a unique UUID to each Kafka message and deduplicates on the consumer side.

Event Sourcing for Rollback

All points changes are stored as immutable events. When historical events are corrected, the system rolls back to the checkpoint before the error and replays subsequent events, similar to database log replay.

DSL Rule Engine Built with Go

A domain‑specific language (DSL) expressed with Go syntax lets operators define rules such as event_type=="answer_is_liked", 250. Rules are stored in a database, loaded at startup, and interpreted without recompiling the service.

Technical Stack

The service is implemented in Go, uses PostgreSQL for durable storage (including JSON fields for flexible event data), runs inside Docker containers, and communicates via a Kafka message bus.

Conclusion

The points system demonstrates how a simple, well‑designed Event Sourcing architecture combined with a Go‑based DSL can provide a maintainable, extensible solution for complex business rules while keeping the implementation lightweight and elegant.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DSLGoKafkaEvent SourcingPoints System
GF Securities FinTech
Written by

GF Securities FinTech

Dedicated to sharing the hottest FinTech practices

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.