Skip to content
This repository has been archived by the owner on Feb 6, 2025. It is now read-only.

System design

Piotr Gankiewicz edited this page Dec 9, 2016 · 11 revisions

The design of Coolector system is heavily based on the microservices and CQRS patterns. What does it mean in practice? Let's see:

  • Each service is an independent project (as well as the repository), therefore it can be developed and deployed with its own lifecycle without interfering the other parts of the system.
  • Services focus on a single domain and responsibilities that are related to the entities. For example handling user authentication is a totally different task than filtering the remarks.
  • Services can easily scale independently from each other. All you need to do is to spawn a new instance of the particular service - the horizontal scaling has a much bigger advantage over the vertical one.
  • Services have no idea about the other parts of the system - they're just "unit of work" that processes the commands and publishes events. Loose coupling is the key while designing microservices.
  • CQRS allows separating reads from writes, which eventually turns into much easier scaling as you can easily distinguish between the commands and the queries.
  • Data is being held in a very efficient, read-only storage that contains already "flattened" objects ready to be returned to the end users directly.

Having the general overview of the Coolector architecture, let's describe the core parts of the system:

  • API - acts as a gateway to the whole system, that receives the user requests (translated into commands and queries) via HTTP requests. It is aware only of the service bus for publishing the commands and the storage service which is being used for retrieving the data via queries.
  • Storage - handles storing the data using its internal database. It does subscribe to the particular events in order to fetch the data from a particular service and "flatten" the object accordingly so it's directly ready to use by the end user. The data storage client which is the API in our system is not being aware where does the data come from (storage database, cache, some other service etc.) which makes this service a truly transparent data provider.
  • Services - a set of microservices that are independent of each other (and also unaware of anything else), which are being tied to the specific domain and business logic.
Clone this wiki locally