Microservice Basic - Blog (1)

MicroService Basic + Blog Example

Quite interested at learning new things… Thus, why not start learning Microservice from now?

The banner image shows a traditional snack 冰粉 (bing fen) that I used to have almost every day in my home city. It has both a sour and sweet taste with ice underneath. Different vendors have their different recipes with what items you can put into, but they all share items such as watermelon, bing fen (the transparent, jellyfish-like thing.)
My memory about bingfen always comes with the mid-summer where there is no better dessert compared to a bowl of bingfen that can cool me down. In fact, it is not hard to make bingfen at home. Even here in the states, I found there is bingfen powder in Asian supermarkets that allows you to directly make it in your kitchen. Interestingly, the origin of bingfen is seeds of the shoo-fly plant, which is also called the apple of Peru originated from South America.

Microservice Basic

Basics + Post Example

What is microservice

Monolithic Server






Each service is self-contained!

In summary: A single microservice contains all

  • Routing
  • Middlewares
  • Business Logic
  • Database access

to implement one feature of our app

Data Management Problem

Microservice has a problem of data management between services



  1. Each service has its own database (database per service)
  2. Service will never reach into another service’s database
    1. good scale capability
    2. low coupling (less dependency, more reliability, no single point of failure)
    3. optimize by choosing the best-fitted database

In monolithic design, adding new service is easy as it only access to a single DB

In microservice, it is really hard!

General strategy to solve data communication problem

  • Sync
    • direct requests between services
    • drawback:
      • dependency between services, forming net of dependency
      • single point of failure!
      • slowest request is determinant
  • Async
    • events driven
      • all services wire to Event Bus, let Event Bus handle what should each service do in response to event
      • drawback:
        • almost same as Sync service
    • let the additional service has its own database
      • other service can emit events to event bus so that other can listen to it and update DB accordingly.
      • Good:
        • No dependency
        • Extremely fast
      • Drawback:
        • data duplication (extra storage, however, is relatively free nowadays)
        • hard to understand

接了一个 三小时多的 hands-on app blog 🥲 好长


Async Event Driven Fetch Posts+Comments

We see that to achieve the purpose of GET+POST, we need to do multiple requests to the same route, which is not efficient at all.

We can introduce a Query Service that assembles all of the blogs + comments into an efficient data structure.

When other services emit the event, Query service receives and does thing regarding it

→ Send event


→ Create a post (in query service)


→ Send event


→ Create comments (in query service)


This type of solution

  • Good: has no dependency
  • Good: query service is very fast
  • Bad: duplicate data
  • Bad: hard to hard


Event Bus


Event bus did what events should be emit to other services


Comment Moderation

In a comment moderation service, the best approach is to let moderation handled by the comment service and emits a generic event CommentUpdated . We do not want too many types that require each service to handle!


Therefore, the overall data flows like:

  1. User submit comments
  2. Event CommentCreated event to Event Bus
  3. Moderation and Query service received this event
  4. Moderation Emit CommentModerated with a updated event
  5. Comments service received the event and change status to Approved
  6. Emit CommentUpdated event to Event Bus
  7. Query Service update the comments based on event


If one of the service is lost, how do we handle it?

  1. Sync Requests, fetching posts/comments from query service at all time and sync with its local DB
  2. Direct DB Access, sync service’s local database with each other once a event is emitted.
  3. Store Event, Store events in a Event Bus Data Store.

See the third approach in the example code base!

Thank you for reading along this article