From 04a98232f3e70216d350300318e94179c4a0af60 Mon Sep 17 00:00:00 2001 From: Tapasweni Pathak Date: Mon, 10 Oct 2022 10:30:27 +0530 Subject: [PATCH] Refinement to existing documentation on the enhanced ability to separate read/write/batch API operations for greater performance --- .../docs/en/chapters/architecture/design.adoc | 28 +++++++++++++++++++ .../en/chapters/architecture/principles.adoc | 28 +++++++++++++++++++ 2 files changed, 56 insertions(+) diff --git a/fineract-doc/src/docs/en/chapters/architecture/design.adoc b/fineract-doc/src/docs/en/chapters/architecture/design.adoc index ce68dc22c4e..57bf82f760b 100644 --- a/fineract-doc/src/docs/en/chapters/architecture/design.adoc +++ b/fineract-doc/src/docs/en/chapters/architecture/design.adoc @@ -40,3 +40,31 @@ NOTE: if a RollbackTransactionAsCommandIsNotApprovedByCheckerException occurs at * Process command using handler (In transactional scope). * CommandSource object created/updated with all details for logging to 'm_portfolio_command_source' table. * In update scenario, we check to see if there where really any changes/updates. If so only JSON for changes is stored in audit log. + += Instance Types Configuring Capabilities to Fineract + +Now, Fineract has enabled performance enhancing separation of three instance types, +i.e., read, write, and batch. + +Using environment variables, the three instance types performance enhancing +operation separation can be performed: + +* FINERACT_READ_MODE_ENABLED +* FINERACT_WRITE_MODE_ENABLED +* FINERACT_BATCH_MODE_ENABLED + +Where each of the environment variables represent each of the capabilities of +the different instance types; configuring all of them to true will mean the +current state of Fineract - i.e. a single instance in default will be capable of +serving every functionality Fineract has right now. + +For backward compatibility reasons, all 3 environment variables have true values +so that it's easy to kick off a single instance deployment and to give the +potential to bigger deployments to utilize this type of splitting. + +This makes 4 modes: + +* Full mode (default) +* Read mode +* Write mode +* Batch mode diff --git a/fineract-doc/src/docs/en/chapters/architecture/principles.adoc b/fineract-doc/src/docs/en/chapters/architecture/principles.adoc index f1eecf12e80..d5f13b9ad18 100644 --- a/fineract-doc/src/docs/en/chapters/architecture/principles.adoc +++ b/fineract-doc/src/docs/en/chapters/architecture/principles.adoc @@ -31,6 +31,34 @@ Why? There are numerous reasons for choosing this approach which at present is n * Used to support a general approach to *maker-checker*. * State changing commands use the Object-Oriented paradign (and hence ORM) whilst querys can stay in the data paradigm. +== Read/Write/Batch API Operation Separation + +Fineract now has 3 different Fineract instance types, you can find detailed documentation https://github.com/apache/fineract/blob/develop/fineract-doc/src/docs/en/chapters/deployment/instance-type.adoc. + +All 3 different instance types: + +* read +* write +* batch + +has a few performance enhancing restrictions in terms of what they are capable of. + +For example, a read instance is going to be only capable of serving read (GET) +APIs. Write APIs will be able to serve both read and write APIs. Batch instances +will be only able to serve batch job related APIs and run the batch jobs themselves. + +This greatly improves performance in terms of how we can scale Fineract in case +we're planning to deploy it to a highly-available setup with the highest +throughput because we can scale individual parts of it. + +As an instance, reading data happens much more often than actually writing data +so the ability to do this type of deployment will greatly improve what we can +achieve in terms of performance. + +With separation in place, we could utilize read-replica databases as well where +where write and batch instances connect to a master DB and the read instances +connect to read-replicas therefore reducing the load on the database as well. + == Maker-Checker Also known as *four-eyes principal*. Enables apps to support a maker-checker style workflow process. Commands that pass validation will be persisted. Maker-checker can be enabled/disabled at fine-grained level for any state changing API.