Nagoya Foundation
Published in

Nagoya Foundation

A simple architecture for cache or web-socket layers

This is how I designed state-full services using a very simple architecture to keep them in sync

Model using MongoDB

The model using MongoDB deserves special attention because it has the ChangeStreams feature: ChangeStreams let you stream operations from the DB on real time. In other words it is a simple op log, but on steroids. You can read their docs [1,2] to get a better insight. What I like about using MongoDB for this is:

  1. Tiny latency
  2. Query flexibility, event selection
Example configuration with cache and MongoDB

Variation: readers and writers

One other way to organize your services is having different readers and writers.

Configuration with a write only service

Message delivery solution

This is already very close to the solution for the message delivery problem, in that scenario the writer service is the API to send a message to a user or a group. That message is simply saved on the database, which is great, that service cares only about receiving users' requests and storing them. That message, saved on a specific collection, is then distributed to all connected instances of the message delivery service, which just distributes to the connected users to that instance which are addressed by the message.

Solution for message delivery problem

Using Debezium

You may me wondering: OK, but I don't use MongoDB. No problem! Just use Debezium. Use this platform to stream changes from a huge set of sources, as themselves say:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store