SafePeak Architecture: Learn how it works

SafePeak acts as a proxy cache between application servers and database servers. Patent-pending auto-learning caching algorithms store SQL statements results in SafePeak RAM, greatly reducing database-server load, eliminating traffic bottlenecks and increasing scalability and transaction throughput.

SafePeak self learning algorithms manage up to 95% of cache configuration. By analyzing both the database schemes (metadata) and the data traffic consumption (sql queries and stored procedures) and using mathematical models and data mining techniques, SafePeak creates optimized caching patterns and improves them over time. SafePeak cache supports read-write database transactions and isdynamically modified by a coherence protocol, ensuring 100% data integrity at all times. Optional manual configuration allows customers to perform fine-tuning optimizations, by specifying their unique, pre-defined use-cases.

SafePeak result set cache coherence protocol ensures 100% data integrity for both read and write database transactions.

SafePeak Cache Management

Transaction Flow

When a SQL query is issued from a web-based or enterprise application, SafePeak intercepts the query and determines whether to direct the query to the SQL Server database for processing or to return the query response from the SafePeak Cache Manager.

SafePeak examines whether the query is a repetitive read query whose results have been stored in SafePeak's RAM memory; whether the query is new and needs to be sent to the SQL Server database for retrieval; or whether the query is a write request (update, insert, delete or other DDL/DCL types) that causes a change in the target database (and possibly the cached results) and needs to be forward to the SQL Server database for execution. The major scenarios and flows are described in detail below:

SafePeak Cache Patterns

Scenario One - Query Result Returned By SafePeak

The first action that SafePeak takes is to determine whether the transaction contains a repetitive query whose result set is stored in the SafePeak Cache Manager in RAM memory. If the query is found to exist, the result set is retrieved from the Cache Manager (C1) and returned to the querying application (C2).

No further action is taken by SafePeak and the query never needs to reach the target database. In this scenario, the query cache holds the exact results that are sent to the querying application in a low level binary result set. When the query comes in, SafePeak does a very fast check to see whether the query is identical and then sends the stored results as in figure 1 below.

Figure 1 - Query Result Returned By SafePeak

The ability to rapidly retrieve identical result sets significantly improves response time, reduces overall network and database traffic and gives a boost to system scalability, especially at times of peak usages and spikes in demand.

Scenario Two - Query Result Returned by Database; Result Stored In SafePeak Memory

In scenario two, SafePeak checks and determines that the query and result set are not stored in the Cache Manager. SafePeak continues to process the query and determines whether the request is a read query or a write request. In the scenario illustrated below in figure 2, we have determined that the request is a read query (Q1).

SafePeak takes several steps at this point. The first step taken by SafePeak is to process the query on the target database and return the result set to the querying application to ensure the most rapid response possible (Q2).

Once the information has been sent to the querying application, SafePeak determines if the query is a repetitive cacheable query. If it is, then SafePeak saves its result set in binary code inside the RAM memory of the Cache Manager (Q3) to be accessed upon the next instance of the identical query.

Figure 2 - Query Result Returned by Database; Result Stored In Cache Manager RAM

Scenario Three - Eviction of Results Set In Cache; Update to Database

In scenario three, SafePeak determines that the incoming query is an update, insert, alter or any other request that may cause a change in the database. In this case, SafePeak dissects the request and decides which tables in the database may be affected by its execution. It then looks at the query results stored in the Cache Manager and evicts all results that have any connection to the affected database tables (U1).

Once the Cache Manager has been cleaned to ensure data credibility and accuracy, the request is sent to the SQL Server database and executed (U2). The result set of the executed response is then sent back to the querying application (U3). By handling the update requests and eviction of cached result sets in this fashion, SafePeak is able to ensure the highest levels of data integrity and consistency. While the transaction is in progress SafePeak's Cache Manager is locked, preventing new queries to be inserted to the cache with relation to the objects affected by this update request.

Figure 3 - Eviction of Results Set In Cache; Update to Database