In-Memory Persistence Layer for Database Availability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Database failures disrupt software applications by causing unavailability and reducing their performance, as existing systems lack effective backup mechanisms for ensuring high availability during database downtime.

Innovation Solution

Implementing an in-memory persistence layer that dynamically switches to become the primary storage when the database is unavailable, allowing data to be stored and retrieved from this layer, and synchronizing data back to the database once it becomes available, ensuring continuous service availability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If data is stored only in the database layer, then data persistence is ensured, but service availability is reduced when the database becomes unavailable

Engineering Contradiction:
Improveservice availabilityVSAvoidstorage architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The storage system is segmented into two independent layers: database layer for persistent storage and in-memory persistence layer for high-speed access. This segmentation allows the system to operate from the in-memory layer when the database is unavailable, improving service availability while maintaining manageable complexity through clear separation of concerns

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The in-memory persistence layer acts as an intermediary between the application and the database layer. It buffers data operations and can independently serve read/write requests when the database is unavailable, thereby improving reliability without significantly increasing overall system complexity

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If an in-memory persistence layer is added as backup storage, then service availability is improved during database downtime, but system complexity increases

Engineering Contradiction:
Improveservice availability during database downtimeVSAvoiddual persistence layer architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system dynamically switches between database layer and in-memory persistence layer based on database availability. The routing mechanism adapts in real-time, selecting the appropriate storage layer for each operation, which improves reliability during downtime while keeping the complexity manageable through dynamic rather than static architecture

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The in-memory persistence layer serves multiple functions: it acts as a backup storage during database downtime, provides high-speed data access during normal operation, and maintains data synchronization. This multi-functionality justifies the added complexity by delivering multiple benefits from a single architectural addition

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Reliability

If data is written to both database layer and in-memory persistence storage, then data availability is improved, but data consistency challenges arise

Engineering Contradiction:
Improvedata availabilityVSAvoiddata consistency between layers
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The system implements feedback mechanisms through synchronization processes that continuously monitor and update data between the database layer and in-memory persistence layer. When the database becomes unavailable, the system detects this state and routes operations to the in-memory layer, maintaining data consistency through active monitoring and adaptive routing

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

Data is pre-synchronized to the in-memory persistence layer before database operations are performed. This preliminary action ensures that the in-memory layer has up-to-date data ready for immediate access when the database becomes unavailable, improving data availability while minimizing consistency issues through proactive data preparation

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11522975B2Double persistence layer using an in-memory map
Publication Date: 2022.12.06 SAP SE
  • US11522975B2 patent drawing
  • US11522975B2 patent drawing
  • US11522975B2 patent drawing

AI summary

The present disclosure relates to computer-implemented methods, software, and systems for database persistency. A first data request is received at a first instance of an application. The application is associated with multiple instances that share the database layer. In response to determining that the database is available for accessing after receiving the first request, the database is identified as a primary storage for the application, the data is written in the database and at an in-memory persistence storage of the first instance of the application. In response to determining that the database has become unavailable after identifying the database layer as the primary storage, the in-memory persistence storage is configured as the primary storage for the first instance of the application. A second request received at the first instance of the application is routed to the in-memory persistence storage while the in-memory persistence storage is configured as the primary storage.