Skip to content

Latest commit

 

History

History
44 lines (36 loc) · 3.15 KB

README.md

File metadata and controls

44 lines (36 loc) · 3.15 KB
Raw

README needs update, but it still can help you get an idea on the whole project idea in case you are interested.

Omar-DB

BASE Model Database for Microservices & Monolithic Environments, with ACID support for a cost

This project is a nothing but a POC, and is considered to be moved to Rust Programming Language in the future in case it proves to have exceptional features, to achieve the expected performance of a Database in any environment.

Questions To Be Answered

1- Apache Kafka

  • Should I use Kafka as a message queue for nodes, or is it an over-kill, and maybe I can use or build something simpler?
  • What configuration is needed for Kafka (Templates, Brokers, Messages, ...etc)?
  • Is the default docker environment enough in the used image?
  • How many brokers would I need, can that be customizable by the user?
  • How much time should a message live, can that be customizable by the user?

2- Security

  • Is Spring Security good for the task?
  • Can it handle SSH sessions too?
  • Should I provide more than one method for authentication?
  • What method should I use to manage sessions (most likely through token based authentication)?

3- API

  • Should I use REST or GraphQL?
  • If I used GraphQL, can I simply provide an open-access to all tables, or should that be an option on users end?
  • Is gRCP an option, and what are the advantages?
  • Should I forget about the Web API idea and simply provide a programmatic API/SDK?
  • Would SSH connections be of any advantage?

High-Level Architecture Design Notes & Decisions

1- Master Nodes:

  • They are responsible for handling Write actions.
  • All nodes are connected with each other following what is almost a P2P protocol.
  • By default, there will be 3 Master Nodes, which are replicas of each other, this number can be configured by the user.
  • There is a Publisher-Subscriber relationship between all Master Nodes, if a node approves a write action and once completed, a Write Event will be published, such that all other Master Nodes can replicate the results.
  • Write Events will be published to a Master Nodes Event Board, which can be accessed only by a Master Node
  • Replicating any published event shall be done by a separate thread, which should be limited depending on the availability of resources in each node, such that nodes stand still in their comfort zone.

2- Slave Nodes

  • They are responsible for handling Read actions.
  • Each Master Node has by default 3 Slave Nodes as children, which are replicas of their parent Master Node, this number can be configured by the user.
  • There is a Publisher-Subscriber relationship between any Master Node and its Slave Nodes, if a node approves a write action and once completed, a Write Event will be published, such that all its Slave Nodes can replicate the results.
  • If a Master Node approves and completes a Write Event, and in order for its Slave Nodes to replicate the results, Write Events will be published to a Slave Nodes Event Board, which can be accessed only by the Slave Nodes of the publisher Master Node.

diagram