Microservices Toy Blog App w/ Stephen Grider
General Architecture.
- The features of the blog are to allow a user to create posts and add comments to these posts.
- The posts and comments services keep internal track of the posts and comments that have been created so far, but the client does not read from these services.
toy-microservices-blog-e1.excalidraw
⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠
Text Elements
Query Service
Posts Service
Comments Service
Event Bus
event {postId, title}
post service saves post, sends PostCreated event to event bus
query service subscribes to PostCreated event
maintains knowledge of posts & comments
Link to original - The client makes GET requests to
QUERYSERVICE/posts, which keeps itself updated on both posts and comments by subscribing toPOST_CREATEDandCOMMENT_CREATEDevents, which are emitted by the post and comment services respectfully, and distributed by the event bus service.
What if we want to add comment moderation?
- We could create another moderation service, which now also listens to
COMMENT_CREATEDevents.- The query service would first save these comments in its internal stores as having a status of
pending, and then would be updated on some other event such asCOMMENT_MODERATED. - The issue with this approach is that we do not want business logic in a query service, which should really only serve one purpose (especially if our logic gets more and more complex).
- The query service would first save these comments in its internal stores as having a status of
- We should really have the comments service deal with comment business logic!
- We’ll have the comments service subscribe to the
COMMENT_MODERATEDevent, and have it emit a genericCOMMENT_UPDATEDevent once it handles theCOMMENT_MODERATEDevent however it would like.- This way, all the comment business logic is abstracted, allowing other services to interact with comments without having to know anything about the internal business logic.
toy-microservices-blog-moderation.excalidraw
⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠
Text Elements
Posts Service
Moderation Service
Query Service
Event Bus
comment {postId, content}
comment created
Comments Service
Posts Service
Comments Service
Query Service
Event Bus
Moderation Service
COMMENT_UPDATED
- After moderating, comments service subscribes to COMMENT_MODERATED and updates internal comment data.
Posts Service
Comments Service
Query Service
Event Bus
Moderation Service
COMMENT_CREATED
- After comment is updated, query service subscribes to COMMENT_UPDATED and updates its internal data.
COMMENT_MODERATED
query service will save comment with status: pending
Link to original
- This way, all the comment business logic is abstracted, allowing other services to interact with comments without having to know anything about the internal business logic.
- We’ll have the comments service subscribe to the
How do we deal with services going down?
- What happens if a service goes down for a while, or if a new service is added later in the lifecycle of an app?
- The previous events that happened when the new/down service wasn’t up will be lost to time.
- We can add a data store in the form of a database to the event bus, so that we have a history of the events we have sent!
- Now, new services can go through all events of the past, and services that went down can look up all of the events that occurred while it was down.
- Whenever a service comes online, we can have it ask the event bus to send it any of the events it may have missed since it last went offline.
Categories:: microservices