Both systems had 32 GB of RAM, four attached solid state disks, and were running RHEL 5.4 operating system:

Dunnington Server: 4 x CPU Intel Xeon 7450 @ 2.4 GHz, total 24 cores

Nehalem-EX Server: 4 x CPU Intel Xeon 7560 @ 2.27 GHz, total 32 cores

The results are shown in Figure 7-6. The throughput peaks at more than a million transactions per second.

Figure 7-6 TATP Benchmark 2, throughput as a function of client load

7.4.2 Financial services

Financial systems are tremendously data-intensive and rely on speed in trading transactions that can result in huge profits and help exchanges compete and meet client demands. As market volatility continues to increase so does the risk of system failures that can lead to transaction delays, with a direct impact on the global financial system and the businesses and individuals that rely on it.

The broad applicability of solidDB product family in financial services sector is described in 7.4.3, “Banking Payments Framework” on page 243 and 7.4.4, “Securities Exchange Reference Architecture (SXRA)” on page 246. In financial markets, milliseconds can mean the difference between profit and loss. Database performance is often a critical factor in rapidly making a decision to trade, executing that trade, and reporting the trade. It is an even more critical factor considering that trading volumes are growing, and effective trading decisions require more complex analytics of more data.

242 IBM solidDB: Delivering Data with Extreme Speed

7.4.3 Banking Payments Framework

In this section, we use a payments processing environment to demonstrate architectural and design patterns that can benefit from the use of both solidDB server and solidDB Universal Cache.

Introduction

The enterprise payments systems are characterized by the fact that all payment methods share a common set of data elements and processing steps. For example, checks and credit cards can seem different on the surface, but they are actually quite similar. Both have a source of funds, a security model, and a clearing and settlement network. All payment methods also require certain services, such as risk and fraud management. However, regardless of the similarities, in most banks the payment systems exist in silos, closely tied to particular retail and wholesale product lines.

The IBM Enterprise Payments Platform (EPP), also known as the Financial Transaction Directory, is a solution that addresses the common problems of the banking industry, simplifying payment systems by providing banks with a single platform to integrate new and existing payments systems regardless of where they reside.

The EPP is based on WebSphere Message Broker and WebSphere Process Server and DB2 and Oracle database technologies and software. With a service orientated architecture, the platform allows other banking applications to use componentized payment services in support of multiple lines of business. For example, with EPP, banks can purchase or develop one service to handle identity verification requirements and reuse it elsewhere to respond faster to changing regulatory requirements.

The solidDB Universal Cache can be integrated into the EPP. By using the solidDB in-memory cache, critical data can be collocated with the application, thus reducing latency by eliminating the network. The use of the in-memory engine can also speed database operations.

Chapter 7. Putting solidDB and the Universal Cache to good use 243

A schematic view of the EPP framework with solidDB Universal Cache is shown in Figure 7-7. To collocate data with the application, solidDB server can be implemented with SMA or LLA.

Figure 7-7 IBM Enterprise Payment Platform with solidDB Universal Cache

Benefits of solidDB Universal Cache in a payments system

Some of the key data in a payments system is by nature read-intensive, possibly requiring periodic updates. By caching such data into the in-memory cache, payment systems can benefit greatly from the solidDB Universal Cache.

The following sections describe the key payments system areas and the type of data that is suitable for caching with the solidDB Universal Cache.

Payments life cycle

Payment systems are mostly event-driven and asynchronous in nature. The life cycle of payments or batch of payments is thus typically specified through a state machine paradigm. The state machine definitions are rarely updated but they must be read frequently, returning single or small result sets. By caching the state machine definitions into the in-memory cache, the applications can read (and periodically update) the data with low latency.

244 IBM solidDB: Delivering Data with Extreme Speed

Bulking and debulking of payment information

Typically payments are received in bulk. The batch of payments must be processed quickly so that a response on the validity of the batch can be returned to the financial institution’s customer. The processing of the batch information involves the parsing and persistence of multiple payment instructions and the validation and construction of various object relationships in the database. This process is readand write-intensive; the bulking and debulking operation is sensitive to latency. Again, the applications can benefit from caching the batch information data into the solidDB in-memory cache.

Payment operational data

Various decision points in the payments life cycle rely on processing relational transaction data, such as the value of the transaction, the destination of the transaction, the currency of the transaction. This type of data affects the processing path of the payment and hence needs to be accessed frequently with a low latency requirement.

Reference lookups

The payment processing includes several enrichment, legal, and processing data list lookups that are by definition read-intensive. For example, using the in-memory cache can accelerate access to the following types of lookup data:

Fee management

Billing

Security

Anti money laundering

Account lookup

Routing

Risk scoring

Negative databases

Liquidity

Exchange rates

The solidDB Universal Cache features that are useful to payments systems

In this section, we describe two solidDB Universal Cache features that can bring additional benefit to the payments systems setups: data aging and SQL pass-through.

Data aging

Data aging is the process by which data is removed from the cache but not from the back-end database. Reciprocally, it also enables only specific data to be moved into the cache initially. The main benefit of data aging is the reduction of the amount of memory that the cache requires.

Chapter 7. Putting solidDB and the Universal Cache to good use 245