A real story: shifting from API calls to Event Notifications

Microservices system architectural pattern has been applied to HK01 two years ago since transforming HK01 from a media to a life platform. A number of businesses have been launch like user-generated content(撐場), Event Management, Ticketing Service, Payment Service, Eatojoy (e肚仔), Charity (01心意), membership point (會員積分）, coupon, running reward program (01齊跑). This architectural pattern is good for HK01 use cases, making business domains separated, loosely coupled so that to facilitate better scalability and maintainability. It enables automated build, test, and continuous delivery with minimal impact to other business domain.

“Rome wasn’t built in a day”. We haven’t tried to build ALL microservices foundation from day-1, but improving it gradually depends on our real needs. API callbacks (a.k.a webhook) had been used to handle system side effects previously. There was a big challenge that the dependency became more and more when adding new systems. Both implementation and maintenance effort grow exponentially. We found that it is extremely painful when we want to implement a membership point service.

Use case: The service will grant certain points/coupon to a user if

A customer purchases an item from the eCommerce service.

or, she attends an event via our Event Management.

or she donates $n to a specific Charity.

Restful callback approach

There are drawbacks to using this approach,

1. Both upstream and downstream required code changes.
2. Upstream and downstream systems with high deployment dependency
3. Upstream system performance will be affected if downstream systems response slow, or upstream required additional work to avoid backpressure issue.

Thus, we found that migrating to an Event Notification architecture is more suitable as our business grew.

Event Notification

A system sends event messages to notify other systems of a change in its domain. [Martin Fowler, What do you mean by “Event-Driven”?]

Event Notification allows a system to “announce” something happened in its business domain and other systems handle side effects by itself. This is a great idea to reduce systems coupling, the upstream system without any knowledge to downstream systems that means no webhook needed in this design. It required an Event Stream / Message broker for :

• upstream services to publish an event message
• downstream systems to subscribe/consume the event message

Use case of event notification in HK01

With Event Notification, upstream services without any knowledge of Membership Point Services so that they can fire and forget. Downstream service, Point Service eventually grants points to end-consumer depends on its rules, logic, and loading. Downstream service throughputs and availability will not affect upstream services. Upstream services are not required any code change if stakeholders want to add a new grant point rules based on existing events. In HK01, we picked RabbitMQ and make use of the Topic Exchange model for Event stream and Google ProtocolBuffers for message schema.

Summary

Event Notification is good for handling side effects if eventual consistency is acceptable in your use case. Developers should confirm this with the product owner before applying this architectural pattern.

Thanks for reading. If you enjoyed reading this article, feel free to support us by hitting the clap button 👏 and to help others finding this article. We are hiring, job descriptions can be found HERE. You are welcome to drop me a message if further questions.