Microservices Architecture Example - Part 3

Intro

In Part 1 of this series we took a look at the high level user stories for a niche directory site that I'm building. In Part 2 discussed the authentication and authorization approach.

In this article we'll look at some of the core microservices that contstitute the site's logic.

Orgs and Events

Organizations and events are our key constructs for the site - but they are almost identical in terms of functionality.

I considered having events as a property of an org, and collapsing this into one service. However events can also be independent of a listed org, and I did not want to limit the types of events being listed by tying it to a registered org. Hence the two are different microservices.

Submissions

Submission of data to the site is key to users being able to share information pertinent to the community. We want for users to be able to submit events, organizations, and feedback without necessarily being authenticated - we want to make it as easy as possible. This does mean we'd want to have a site administrator review, and edit submissions before listing it on the site.

Submission functionality could lie in the Org or Events microservice - however since this is just largely free-form text (to make it easy for users), it makes sense to separate this service out and have it handle different types of submissions (orgs, events, feedback, images etc). An approved submission can then be moved added by the Org or Event microservice when approved.

Stats and Notifications

Tracking of site stats e.g. org hits, event hits, followers added, upvotes etc. We want this to be generic and open for future extension as well. We also need to be able to pull those stats as reports.

The stats service can feed into a Kafka stream, with events being picked up and actioned accordingly. I have not gotten this far yet :)

Notifications will be via email. Not just to users but also to Site Admins letting them know for example when a new event was submitted and to go and approve it.

Wrap up

This is essentally the end of design line. We have identified what micro-services we need, and what functionality they provide. Below is the consolidated picture of the microservice mapping.