Overrides/Supersedes 

This decision was migrated from the Tech Leads Decision Log as part of a consolidation process.  The original decision record can be found here.

RFC 

N/A

Stakeholders

• Front-end and back-end devs who meet issues with data consistenc

Contributors

Raman Auramau 

Approvers

Background/Context

Overview

There's interest in determining the minimal set of modules to run a bare-bones FOLIO instance.  The expectation is that we'll likely find modules which are currently required, but shouldn't be (e.g. inventory/inventory-storage).  Ideally we can address these situations and define a "platform-minimal" that makes sense, and would allow the FOLIO platform to be used for non-LSP application development.

Motivation

The motivation for this work is twofold:

• Both the Technical Council and various interest groups (TL, SysOps SIG, etc) discussed the complexity stemming from the fact that FOLIO consists of large and an ever-growing number of distributed but highly inter-connected modules. This complexity creates operational, architectural and scalability challenge for developing, shipping and running FOLIO. It's been discussed that un undertaking to analyse and potential limit or reorganize dependencies in FOLIO should be started in FOLIO but no specific details or next steps have been agreed on. The activity to define "platform-minimal' is seen by some members of the TL as an activity that could kick-start this process by analysing and reorganising dependencies for the so-callled "core" set of modules
• The team behind Sinopia (Entity editor to become part of FOLIO)expressed a need for the minimal version of the FOLIO platform to allow their existing users to continue running Sinopia during the transition to the FOLIO platform.

Assumptions

N/A

Constraints

N/A

Rationale

Decision

Implications

• Pros
  • N/A
• Cons
  • N/A

Other Related Resources

Meetings notes

19 May 2021 Agenda

• Review current context of FOLIO Data Consistency
• Review identified groups of Data Consistency issues - are there any to be added?
  • added a new one for update collisions
• What are the priorities?
• Review a proposed solution for Eventual consistency for redundant data
• Identify next steps

30 Jun 2021 Tech Leads meeting

• Communicate the proposed solution for Eventual consistency for redundant data on Tech Leads meeting
• Next steps from my end - no objections from Tech Leads to go ahead
  
  • I do propose to consider a FOLIO Domain Event Bus on top of Kafka as a potential pattern (without strong committing on this right now)
  • Need to work though this in all the details during implementation for a particular case (Thunderjet team has some examples)
  • After that - document and review the design and implementation, and present on Tech Leads meeting as a detailed design
• Action items:
  • Sync with Charlotte W regarding the cross apps consistency
  • Chat with Mikhail F and Vladimir S regarding Kafka usage including topic naming conventions etc.
  • Meet with Thunderjet team and Dennis B to agree on capacity and planning
  •  Raman to continue design work and keep in mind Jacub's proposal (see in comments)

06 Jul 2021 Thunderjet grooming session

• Raman shared current status and suggested plan; Thunderjet is ok to go ahead
• UIREC-135 - Update create, edit and receive piece forms with additional fields CLOSED - this is a top priority issue with data consistency for duplicated data which is necessary for current Thunderjet feature completion; agree to start with this issue
• Raman to work with Andrei Makaranka on details