[
https://issues.apache.org/jira/browse/FINERACT-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519966#comment-17519966
]
Arnold Galovics commented on FINERACT-1571:
-------------------------------------------
> I'm assuming that initially the instances would share the same database and
> would only consist of the application instance - correct?
Correct. So the technical implementation will be something like "configuring
capabilities to Fineract" using environment variables. For example the 3
environment variables will be available for configuration (we can change the
naming if needed):
* 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 env variables will 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.
> And then as second step we could create a separate read-only replica database
> for the read instances, whilst keeping the write / batch instances pointing
> at the "master" database?
Correct. This is definitely one type of deployment model which everybody can
vary according to their plans and needs.
> I'm assuming the first step would be to start classifying / declaring APIs to
> be read-only vs write, so that it's clear which APIs can be called on the
> read instance. I'm assuming this is pretty straightforward in most cases,
> though I think we do need to confirm that the read APIs do not have any "side
> effects".
So the idea was to simply denote HTTP GET APIs as "read" and the rest is
"write" except the ones for the batch jobs. But you had a good point, audit
trailing, that's something I haven't checked but a potential solution could be
for a read instance to keep a write database connect as well just for these
type of purposes.
Hope this makes sense.
> Read/write/batch separation
> ---------------------------
>
> Key: FINERACT-1571
> URL: https://issues.apache.org/jira/browse/FINERACT-1571
> Project: Apache Fineract
> Issue Type: New Feature
> Reporter: Arnold Galovics
> Assignee: Arnold Galovics
> Priority: Major
>
> The goal of this ticket is to introduce the notion of 3 different instance
> types for Fineract:
> * Read instance
> * Write instance
> * Batch instance
> Each instance type comes with different restrictions. The specifics can be
> found in the table below.
> || ||*Read instance*||*Write instance*||*Batch instance*||
> |*Using only read-only DB connection*|Yes|No|No|
> |*Batch jobs are automatically scheduled or startable via API*|No|No|Yes|
> |*Can receive events (business events, hook template events)*|No|Yes|No|
> |*Can send events (business events, hook template events)*|No|Yes|Yes|
> |*Read APIs supported*|Yes|Yes|No|
> |*Write APIs supported*|No|Yes|No|
> |*Batch job APIs supported*|No|No|Yes|
> |*Liquibase migration initiated upon startup*|No|Yes|No|
> This will help scaling Fineract's individual parts for highly-available and
> high-throughput systems.
> Also, this will make it possible to utilize read-replica databases.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
