FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
SYSTEM AND METHOD FOR REPLICATING BLOCK OF TRANSACTIONS FROM
PRIMARY SITE TO SECONDARYSITE
Applicant
Tata Consultancy Services Limited A company Incorporated in India under The Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION
The present invention relates to replicating data's from Data Centre of the Primary Site to Disaster Recovery Site and more particularly relates to a system and method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site.
BACKGROUND OF THE INVENTION
Disaster Recovery (DR) planning has been mandatory in most large organizations and is typically implemented by having a DR site/Secondary site (SS) which takes over whenever the primary site is down. The DR site/Secondary site has either a full replica or a reduced footprint of the IT infrastructure of the primary site. To ensure that the Recovery Point Objective (RPO) at the DR site/Secondary site is kept as small as possible there is real time replication between the Data Centre (DC) of the primary site and the DR site/Secondary site.
The farther the DR site/Secondary site from the primary site the safer is the protection against calamities. However, keeping the DR site/Secondary site far means a greater lag in replication times between DC of the primary site and DR site/Secondary site. Within the limits of a country itself propagation delays can be of the order of ten to hundred milliseconds. This prohibits synchronous replication for applications such as core banking or stock trading that warrant high throughput.
As a result large organizations often go for a two way replication. First, there is a near site to which application logs get synchronously written. And then there is a traditional DR site/Secondary site to which application logs are asynchronously written. If there is a major failure at the DC of the Primary site the logs are taken from the near site. If the near site also fails only in that event, there will be a loss of data (transactions in progress at the time of failure and transactions in transit to DR site/Secondary site) at the DR site/Secondary site.
In the state of the art, various types of Disaster Recovery (DR) schemes are proposed to solve the above mentioned problems.
One of the proposed disaster recovery replication schemes in the state of arts is an asynchronous replication scheme. In the asynchronous replication scheme, an application

(such as a database) asynchronously ships transaction logs from PS to SS over a network. The SS system keeps receiving (and applying) transaction logs. The PS does not wait for any acknowledgements from SS and keeps continuing to process transactions. The problem in the proposed data replication scheme, sometimes the network link may be slow or may be broken and this can slow down the log writes. To care of this case the application usually writes log files to a storage device and another process takes the log files and ships them over to the SS. It may affect the performance of the proposed system and might not be suitable for applications such as core banking or stock trading that warrant high throughput.
One of the proposed disaster recovery replication schemes in the state of arts is a synchronous log replication. In this synchronous log replication, an application's transaction log at the PS is synchronously written to the SS. Only after the SS acknowledges the log write at its end does the PS treat the transaction as committed and sends the response to the end user. This way it is ensured that any transaction log at the PS is also committed to the SS and that there is no loss of data. However, this scheme suffers from a high performance penalty of performing the synchronous write over a Wide Area Network (WAN).
One of the proposed disaster recovery replication schemes in the state of arts is full synchronous replication. In this full synchronous replication scheme, the application's transaction log at the PS is synchronously processed at the SS. Only after the SS acknowledges that the log has been processed does the PS treat the transaction as committed and sends the response to the end user, in other words this is a two phase commit, where both the PS and SS are in sync wrt each and every transaction. This has higher overhead than the synchronous log replication and the only utility of this scheme is when one wishes to have instantaneous switch over from PS to SS, or if user transactions can be redirected to SS as well by means of a suitable load balancing logic. This scheme is not practical for high online transaction processing (OLTP) transaction rates.
The schemes for disaster recovery replication, mentioned above, work correctly without any assumptions of the applications at hand. However, if one looks at most applications in the IT industry there is sufficient independence in business transactions to warrant a more efficient disaster recovery replication.

The above mentioned disaster recovery replication schemes may not be suitable, in the case of very high throughput and low latency systems like stock exchanges that need tens of thousands of transactions per second (tps), because of their low throughput and high response time constraints.
Thus, in the light of the above mentioned prior art, there is a need for a system and method which:
• provides disaster recovery replication scheme for applications such as core banking or stock trading that warrant high throughput;
• provides disaster recovery replication scheme for applications such as core banking or stock trading that warrant low latency or low response time;
• requires minimum infrastructure;
• reduces the cost of the hardware setup to improve throughput and reduce the latency or response time of the disaster recovery replication system; and
• is easy to deploy on existing systems;
Other features and advantages of the present invention will be explained in the following description of the invention having reference to the appended drawings.
OBJECTIVES OF THE INVENTION
The principle objective of the present invention is to provide disaster recovery replication system and method for applications such as core banking or stock trading that warrant high throughput and low latency or low response time.
Another significant objective of the invention is to provide a system and method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site.
Yet another objective of the invention is to provide a cost effective high throughput and low latency or low response time disaster recovery replication system and method for applications such as core banking or stock trading.

A still another objective of the invention is to provide a disaster recovery replication system and method for applications such as core banking or stock trading that requires minimal infrastructure.
Still another objective of the invention is to provide a disaster recovery replication system and method which can be deployed easily with existing, convention, and traditional systems.
SUMMARY OF THE INVENTION
Before the present methods, and systems enablement are described, it is to be understood that this invention in not limited to the particular methodologies and systems described, as there can be multiple possible embodiments of the present invention and which are not expressly illustrated in the present disclosures. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present invention which will be limited only by the appended claims.
In the disaster recovery replication systems and methods, the farther the DR site/Secondary site from the primary site the safer is the protection against calamities. However, keeping the DR site/Secondary site far means a greater lag in replication times between DC of the primary site and DR site/Secondary site. Within the limits of a country itself propagation delays can be of the order of ten to hundred milliseconds. This prohibits synchronous replication for applications such as core banking or stock trading that warrant high throughput.
As a result large organizations often go for a two way replication. First, there is a near site to which application logs get synchronously written. And then there is a traditional DR site/Secondary site to which application logs are asynchronously written. If there is a major failure at the DC of the Primary site the logs are taken from the near site. If the near site also fails only in that event, there will be a loss of data (transactions in progress at the time of failure and transactions in transit to DR site/Secondary site) at the DR site/Secondary site.

In the case of very high throughput and low latency systems like stock exchanges that want tens of thousands of transactions per second (tps), the near site replication also poses problems.
Accordingly, the present invention provides a disaster recovery replication system and method for applications such as core banking or stock trading that warrant high throughput and low latency or low response time.
In the preferred embodiment of the invention the system for replicating block of transaction data logs from Primary Site to remotely located Secondary Site characterized in having high throughput and low response time comprising:
a) a Primary Site comprises
i. one or more computer workstation for data processing; and ii. a server for storing output data obtained from the data processing by one or more computer workstations, wherein the said one or more work stations communicatively coupled with the server by a communication network;
b) a Secondary Site for storing the replicated data from the said Primary site, wherein the
said Primary Site communicatively coupled with the Secondary Site by a
communication network for replicating block of transaction data logs, the said Primary
Site having processor configured to execute programmed instructions for:
1) defining a block size of "n" transaction data logs;
2) replicating the said block of the transaction data logs from Primary Site to Secondary Site, in case of the block of "n" transactions are available or a timeout occurs;
3) marking the transactions of step (2) under replication as "partially complete" at the Primary Site;
4) receiving the said block of transaction data logs by Secondary Site;
5) sending an acknowledgement to Primary Site by Secondary Site after receiving the said block of transaction data logs;
6) processing either log write or transaction process of the block transaction data logs asynchronously after sending the acknowledgement to Primary Site by Secondary Site; and

7) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.
In accordance with another aspect of the invention there is provided a system for replicating block of transaction data logs from Primary Site to remotely located Secondary Site characterized in having high throughput and low response time comprising:
a) a Primary Site comprises
i. one or more computer workstation for data processing; and ii. a server for storing output data obtained from the data processing by one or more computer workstations, wherein the said one or more work stations communicatively coupled with the server by a communication network;
b) a Secondary Site for storing the replicated data from the said Primary site, wherein the
said Primary Site communicatively coupled with the Secondary Site by a
communication network for replicating block of transaction data logs, the said Primary
Site having processor configured to execute programmed instructions for
1) defining a block size of "n" transaction data logs;
2) replicating the said block of the transaction data logs from Primary Site to Secondary Site, when the block of "n" transactions is available or a timeout occurs;
3) marking the transactions of step (2) under replication as "partially complete" at the Primary Site;
4) receiving the said block of transaction data logs by Secondary Site;
5) processing either log write or transaction process of the block transaction data logs asynchronously by Secondary Site;
6) sending an acknowledgement to Primary Site by Secondary Site after processing the said block of transaction data logs; and
7) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.
The above said systems are preferably a core banking or financial trading system but also can be used for many other applications.

BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing summary, as well as the following detailed description of preferred embodiments, are better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings example constructions of the invention; however, the invention is not limited to the specific methods and system disclosed. In the drawings:
Figure 1 is a block diagram of the system for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to the invention.
Figure 2 is a flowchart illustrating a block Ack Replication method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to one exemplary embodiment of the invention.
Figure 3 is a flowchart illustrating a block Sync Replication method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to another exemplary embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
Some embodiments of this invention, illustrating all its features, will now be discussed in detail.
The words "comprising," "having," "containing," and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.
It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, the preferred systems and methods are now described.

The disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms.
Definitions:
Data Processing: The storing or processing of data by a computer is called data processing, wherein the data can be audio, video, text, image, html, etc. The data processing can be used in applications such as core banking and stock trading, etc.
A method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, which are connected by a communication network, characterized in having high throughput and low response time, wherein the said method comprises the computer-implemented steps of:
a) defining a block size of "n" transaction data fogs;
b) replicating the said block of the transaction data logs from Primary Site to Secondary Site, in case of the block of "n" transactions are available or a timeout occurs;
c) marking the transactions of step (b) under replication as "partially complete" at the Primary Site;
d) receiving the said block of transaction data logs by Secondary Site;
e) sending an acknowledgement to Primary Site by Secondary Site after receiving the said block of transaction data logs;
f) processing either log write or transaction process of the block transaction data logs asynchronously after sending the acknowledgement to Primary Site by Secondary Site; and
g) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.
In the disaster recovery replication systems and methods, the farther the DR site/Secondary site from the primary site the safer is the protection against calamities. However, keeping the DR site/Secondary site far means a greater lag in replication times between DC of the primary site and DR site/Secondary site. Within the limits of a country itself propagation delays can be of the order of ten to hundred milliseconds. This prohibits synchronous

replication for applications such as core banking or stock trading that warrant high throughput.
As a result large organizations often go for a two way replication. First, there is a near site to which application logs get synchronously written. And then there is a traditional DR site/Secondary site to which application logs are asynchronously written. If there is a major failure at the DC of the Primary site the logs are taken from the near site. If the near site also fails only in that event, there will be a loss of data (transactions in progress at the time of failure and transactions in transit to DR site/Secondary site) at the DR site/Secondary site.
In the case of very high throughput and low latency systems like stock exchanges that want tens of thousands of transactions per second (tps), the near site replication also poses problems.
Accordingly, the present invention provides a disaster recovery replication system and method for applications such as core banking or stock trading that warrant high throughput and low latency or low response time.
Figure 1 is a block diagram of the system 100 for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to the invention. A system 100 comprises a Primary Site 110 and a remotely located Secondary Site 150, wherein the said Primary Site 110 communicatively coupled with the Secondary Site 150 by a communication network 120. The said communication network 120 can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network and TCP/IP, etc. In one of the preferred embodiment of the invention, the communication network can be telecommunication network. The said Primary site 110 further comprises one or more computer workstation and a server (not shown in the figure). According to one embodiment of the invention four computer workstations 20, 40, 60 and 80 are communicatively coupled with the server by a communication network 120. The said communication network 120 can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network and TCP/IP, etc. In one the preferred embodiment of the invention, the communication network can be telecommunication network. The said computer workstations 20, 40, 60 and 80 are used for data processing. The data

processing can be used in various applications. According to one preferred embodiment, the data processing can be used in applications such as core banking or stock trading. The output of the data processing is stored in the server for recovering the data whenever the data is required. The data stored in the server are being taken back up continuously in a Secondary Site 150.
Whenever the Primary Site 110 fails then Secondary Site 150 support the data processing by providing the data stored therein. The above said Primary Site 110 having processor configured to execute programmed instructions for replicating block of transaction data logs from Primary Site 110 to the Secondary Site 150. The programmed instructions are stored in the server of the Primary Site 110 for driving the said processor for replicating the block of transaction data logs. According to one preferred embodiment of the invention, the Secondary Site 150 can be a server.
The above said processor of the Primary Site 110 configured to execute programmed instructions for replicating block of transaction data logs from Primary Site 110 to the Secondary Site 150 which follows either one of the two methods are as mentioned in the figures 2 and 3.
Figure 2 is a flowchart illustrating a block Ack Replication method 200 for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to one exemplary embodiment of the invention. The above said processor of the Primary Site 110 configured to execute programmed instructions for replicating block of transaction data logs from Primary Site 110 to the Secondary Site 150 which follows below mentioned steps: In the first step 205, the above said processor defines a block size of "n" transaction data logs, wherein the "n" is a configurable parameter which is used to control the throughput and response time; In the next step 210, the processor replicates the the said block of the transaction data logs from Primary Site 110 to Secondary Site 150, whenever the block of "n" transactions are available or a timeout occurs; In the next step 215, the processor marks the transactions under replication as "partially complete" at the Primary Site 110; In the next steps 220 & 225, the secondary Site 150 receives the said block of transaction data logs and sends an acknowledgement (Ack) to Primary Site 110; In the next step 230t the secondary Site 150 as ynchronously continues to process the block (either log write or transaction process) after sending the Ack and in the final step 230, the Primary Site 110 upon receiving

the Ack from the Secondary Site 150 commits all partially complete transactions and sends responses to the one or more end users. According to one preferred embodiment of the invention, the Primary Site 110 sends responses to four end users which are connected to the same.
According to one embodiment of the invention, even while the Primary Site 110 is waiting for the Ack from the Secondary Site 150, it continues to process further transactions as long as business semantics allow it to do so. All transactions that are processed at Primary Site 110 are marked partially complete until their acknowledgement comes in from the Secondary Site 150 by the processor. In most businesses such as core banking or financial services there are hundreds of customers online and tens of thousands of customers whose transactions do not overlap with each other. These fit in naturally with, this proposed disaster recovery replication system and method.
According to one embodiment of the invention, if no Ack is received by the Primary Site 110 within a timeout then either the partially committed transactions are rolled back or a business decision is taken to allow for limited or full services to one or more end users without replication, wherein the timeout is a control parameter to govern response time SLAs. Generally timeout will be set by the administrator. The performance of the above said system and method depends on block size of "n" transaction data logs, bandwidth of the communication network and number of outstanding messages between Primary Site 110 to Secondary Site 150, propagation delay from Primary Site 110 to Secondary Site 150, and timeout parameter.
Figure 3 is a flowchart illustrating a block Sync Replication method 300 for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, according to another exemplary embodiment of the invention. The above said processor of the Primary Site 110 configured to execute programmed instructions for replicating block of transaction data logs from Primary Site 110 to the Secondary Site 150 which follows below mentioned steps: In the first step 305, the above said processor defines a block size of "n" transaction data logs, wherein the "n" is a configurable parameter which is used to control the throughput and response times; In the next step 310, the processor replicates the the said block of the transaction data logs from Primary Site 110 to Secondary Site 150, whenever the block of "n" transactions are available or a timeout occurs; In the next step 315, the processor marks the

transactions under replication as "partially complete" at the Primary Site 110; In the next step 320, the secondary Site 150 receives the said block of transaction data logs; In the next step 325, the secondary Site 150 asynchronously continues to process the block (either log write or transaction process) after receiving the block of transaction data logs; In the next step 330, the Secondary Site 150 sends the acknowledgement (Ack) to Primary Site after processing the said block of transaction data logs and in the final step 335, the Primary Site 110 upon receiving the Ack from the Secondary Site 150 commits all partially complete transactions and sends responses to the one or more end users. According to one preferred embodiment of the invention, the Primary Site 110 sends responses to four end users which are connected to the same.
According to one embodiment of the invention, even while the Primary Site 110 is waiting for the Ack from the Secondary Site 150, it continues to process further transactions as long as business semantics allow it to do so. All transactions that are processed at Primary Site 110 are marked partially complete until their acknowledgement comes in from the Secondary Site 150 by the processor. In most businesses such as core banking or financial services there are hundreds of customers online and tens of thousands of customers whose transactions do not overlap with each other. These fit in naturally with this proposed disaster recovery replication system and method.
According to one embodiment of the invention, if no Ack is received by the Primary Site 110 within a timeout then either the partially committed transactions are rolled back or a business decision is taken to allow for limited or full services to one or more end users without replication, wherein the timeout is a control parameter to govern response time SLAs. Generally timeout will be set by the administrator. The performance of the above said system and method depends on block size of "n" transaction data logs, bandwidth of the communication network and number of outstanding messages between Primary Site 110 to Secondary Site 150, propagation delay from Primary Site 110 to Secondary Site 150, and timeout parameter.
The Proposed disaster recovery replication systems and methods allow for transactions to be processed even while the Secondary Site 150 is yet to respond to an outstanding block. However, no transaction is marked complete until the acknowledgement (Ack) is received from the Secondary Site 150. This allows for high throughput on account of creating a

pipeline of processing with the Secondary Site 150. This provides a cost effective high throughput and low latency or low response time disaster recovery replication system and method for applications such as core banking or stock trading that requires minimal infrastructure and can be deployed easily with existing, convention, and traditional systems.
Note that from an RPO perspective there is no extra penalty imposed by the above mentioned disaster recovery replication systems and methods since transactions are treated as committed only after reception of acknowledgements (Acks).
Performance analysis of Disaster Recovery Replication systems and method:
According to various embodiments, the present invention follows the following relevant terms as mentioned in the Table 1:
Table 1: Notation for Performance Analysis
Notation Description
R Average response time under baseline (no replication scheme)
X. Throughput ftps) under baseline (no replication scheme)
B Bandwidth of link from PS to SS
T Propagation delay from PS to SS (one way)
L Log size (in bytes) for one transaction (that needs to be send to SS)
AL Log write time at SS per transaction
AP Log transaction processing time at SS per transaction
Conventional Method 1 (Baseline: No Replication):
This method serves as a baseline for performance analysis. There is no replication at all, just a primary site PS. if the Primary Site fails there is no recovery possible. The purpose of the baseline is to serve as a comparison for performance. In the absence of any replication, both throughput and response times of applications will be best. The average response time and throughput under no replication are denoted by R and X, respectively.
Conventional Method 2 (Asynchronous Replication):
In asynchronous replication the logs will be written at the rate of X tps. As long as the log
write device can write X*L bytes/sec and the network can write X*L bytes/sec from Primary

Site to Secondary Site, the throughput will be sustained at X tps. Response time per transaction will be increased by the log write time only.
Note that across all the schemes asynchronous replication comes closest to the baseline in terms of R and X, but at the cost of poorer RPO compared to the synchronous schemes.
Conventional Method 3 (Synchronous Log Replication):
After a transaction completes at Primary Site the time to wait for an acknowledgement from
Secondary Site is (2T + L/B + ∆L) units of time. Therefore, the response time (R1) under this
scheme will be greater than R and the throughput (X') will be less than X. We have
R' > R + (2T + L/B + ∆L)
X' < 1/(1/X + 2T + L/B + ∆L)
Conventional Method 4 (Full Synchronous Replication):
After a transaction completes at Primary Site the time to wait for an acknowledgement from
Secondary Site is (2T + L/B + ∆L + ∆P) units of time. Therefore, the response time (R') under
this scheme will be greater than R and the throughput (X') will be less than X. We have
R' > R + (2T + L/B + ∆L + ∆P)
X' < 1/(1/X + 2x + L/B + ∆L + ∆P)
Block Ack Replication system and method:
!n this system and method there is no change to transaction throughput X since processing continues at Primary Site, assuming that the number of outstanding transactions does not cause an overflow. The response time does increase by an additional amount depending on the block size.
For a block size of n transactions (actually transaction logs), and throughput of X tps, the space will fill up in n/X seconds. The response time under this scheme (R') will be: R' = R + n/X + 2π + nL/B
Block Sync Replication system and method:
In the system and method there is no change to transaction throughput X since processing
continues at Primary Site, assuming that the number of outstanding transactions does not

Conventional Method 2 (Asynchronous Replication):
45Mbps with 25% overhead for application messages results in 4.5MB/sec (mega bytes), which at 200 bytes per transaction log results in 22500 transactions/sec without compression. Thus network bandwidth is sufficient for asynchronous replication.
Conventional Method 3 (Synchronous Log Replication): Round trip time for each transaction is at least
2*1 ms + 200/4.5x106 sec + 0.3 ms = 2.34ms This means that the hot stock is limited to 427 trades/sec, which is less than the requirement of 1500 trades/sec.
As a result synchronous log replication will not work for the exchange.
Conventional Method 4 (Full Synchronous Replication):
This has a higher penalty than synchronous log replication and hence this will also not work
for the hot stock requirement.
Block Ack Replication system and method:
For a block size of n, at X=1500 trades/sec for hot stock, we assume that we can tolerate a max delay of d ms. This includes time to fill up the block n/X, plus round trip propagation 2ms, plus transmission time of block n L/B (0.04n ms).
Hence we must have:
n/1500* 1000 + 2 + 0.04n < d that is 0.7 n < (d-2)
For d = 5 ms we need n < 4.28 or 4 transactions worth of buffer size.
Thus Block Ack replication system and method is feasible with an extra delay to response time.
In fact if the Primary Site can handle a higher throughput we can do with a larger n as well if d remains the same. For example if d is 5 ms, then we need 1000n/X + 2 + 0.04n <5

or(1000/X + 0.04)*n<3
or n<3/(1000/X+0.04)
If say X = 10000 tps then n < 3/0.14 = 21.14
This system and method scales well with multiple instances to reach up to 3600 trades/sec if
a single instance can handle 1500 trades/sec.
Block Sync Replication system and method:
The system and method is as above except that we add an additional n ∆L to the delay, which
works out to 0.3n ms for n < 10 and 0.1n ms for larger values of n.
For d = 5 ms this means
1000n/1500 + 2 + 0.04n + 0.3n < 5
for which n =3 will just about suffice for the hot stock of 1500 trades/sec
\1 the Primary Site can handle a higher throughput a larger value of n will work out. For
example if d = 5 ms we need
1000n/X + 2 + 0.04n + 0.3n <: 5
or n<3/(1000/X + 0.34)
If say X = 10000 tps then n < 3/0.44 = 6.88
This system and method scales well with multiple instances to reach up to 3600 trades/sec if a single instance can handle 1500 trades/sec.
The preceding description has been presented with reference to various embodiments of the invention. Persons skilled in the art and technology to which this invention pertains will appreciate that alterations and changes in the described systems and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope of this invention.

WE CLAIM:
1) A method for replicating block of transaction data logs from Primary Site to remotely
located Secondary Site, which are connected by a communication network,
characterized in having high throughput and low response time, wherein the said method
comprises the computer-implemented steps of:
a) defining a block size of "n" transaction data logs;
b) replicating the said block of the transaction data logs from Primary Site to Secondary Site, in case of the block of "n" transactions are available or a timeout occurs;
c) marking the transactions of step (b) under replication as "partially complete" at the Primary Site;
d) receiving the said block of transaction data logs by Secondary Site;
e) sending an acknowledgement to Primary Site by Secondary Site after receiving the said block of transaction data logs;
f) processing either log write or transaction process of the block transaction data logs asynchronously after sending the acknowledgement to Primary Site by Secondary Site; and
g) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.

2) The method of claim 1, further comprising processing further transactions by the Primary Site, in case of Primary Site is waiting for the acknowledgement from the Secondary Site.
3) The method of claim 1, further comprising marking all the transactions that are processed at Primary Site as "partially complete" until their acknowledgement comes in from the Secondary Site.
4) The method of claim 1, further comprising either rolling back the partially committed transactions or taking a business decision to allow for limited or full services to one or more end users without replication, in case of none of the acknowledgement is received by the Primary Site within a timeout period.

5) The method of claim 1, wherein the communication network can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network or TCP/IP.
6) The method of claim 1, wherein the performance of the said method depends on block size of the transaction data logs, bandwidth of the communication network between Primary Site and Secondary Site, propagation delay from Primary Site to Secondary Site, timeout parameter and number of outstanding messages between Primary Site and Secondary Site.
7) A system for replicating block of transaction data logs from Primary Site to remotely located Secondary Site characterized in having high throughput and low response time comprising:
a) a Primary Site comprises
i. one or more computer workstation for data processing; and ii. a server for storing output data obtained from the data processing by one or more computer workstations, wherein the said one or more work stations communicatively coupled with the server by a communication network;
b) a Secon dary Site for storing the replicated data from the said Primary site,
wherein the said Primary Site communicatively coupled with the Secondary Site
by a communication network for replicating block of transaction data logs, the
said Primary Site having processor configured to execute programmed
instructions for:
1) defining a block size of "n" transaction data logs;
2) replicating the said block of the transaction data logs from Primary Site to Secondary Site, in case of the block of "n" transactions are available or a timeout occurs;
3) marking the transactions of step (2) under replication as "partially complete" at the Primary Site;
4) receiving the said block of transaction data logs by Secondary Site;
5) sending an acknowledgement to Primary Site by Secondary Site after receiving the said block of transaction data logs;
6) processing either log write or transaction process of the block transaction data logs asynchronously after sending the acknowledgement to Primary Site by Secondary Site; and

7) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.
8) The system of claim 7, wherein the Primary Site processes further transaction, in case of waiting for the acknowledgement from the Secondary Site.
9) The system of claim 7, wherein the Primary Site marks all the transactions that are processed as "partially complete" until their acknowledgement comes in from the Secondary Site.
10) The system of claim 7, wherein the Primary Site either roils back the partially committed transactions or takes a business decision to allow for limited or full services to one or more end users without replication, in case of none of the acknowledgement is received within a timeout period.
11) The system of claim 7, wherein the communication network can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network or TCP/IP.
12) The system of claim 7, wherein the performance of the said system depends on block size of the transaction data logs, bandwidth of the communication network between Primary Site and Secondary Site, propagation delay from Primary Site to Secondary Site, timeout parameter and number of outstanding messages between Primary Site and Secondary Site.
13) A method for replicating block of transaction data logs from Primary Site to remotely located Secondary Site, which are connected by a communication network, characterized in having high throughput and low response time, wherein the said method comprises the computer-implemented steps of;

a) defining a block size of "n" transaction data logs;
b) replicating the said block of the transaction data logs from Primary Site to Secondary Site, when the block of "n" transactions is available or a timeout occurs;
c) marking the transactions of step (b) under replication as "partially complete" at the Primary Site;

d) receiving the said block of transaction data logs by Secondary Site;
e) processing either tog write or transaction process of the block transaction data logs asynchronously by Secondary Site;
0 sending an acknowledgement to Primary Site by Secondary Site after processing the
said block of transaction data logs; and g) sending responses to one or more end users by Primary Site, after receiving the
acknowledgement from the Secondary Site and subsequently committing all partially
completed transactions.
14) The method of claim 13, further comprising processing further transactions by the Primary Site, in case of Primary Site is waiting for the acknowledgement from the Secondary Site.
15) The method of claim 13, further comprising marking all the transactions that are processed at Primary Site as "partially complete" until their acknowledgement comes in from the Secondary Site.
16) The method of claim 13, further comprising either rolling back the partially committed transactions or taking a business decision to allow for limited or full services to one or more end users without replication, in case of none of the acknowledgement is received by the Primary Site within a timeout period.
17) The method of claim 13, wherein the communication network can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network or TCP/IP.
18) The method of claim 13, wherein the performance of the said method depends on block size of the transaction data logs, bandwidth of the communication network between Primary Site and Secondary Site, propagation delay from Primary Site to Secondary Site, timeout parameter and number of outstanding messages between Primary Site and Secondary Site.

19) A system for replicating block of transaction data logs from Primary Site to remotely located Secondary Site characterized in having high throughput and low response time comprising:
a) a Primary Site comprises
i. one or more computer workstation for data processing; and ii. a server for storing output data obtained from the data processing by one or more computer workstations, wherein the said one or more work stations communicatively coupled with the server by a communication network;
b) a Secondary Site for storing the replicated data from the said Primary site,
wherein the said Primary Site communicatively coupled with the Secondary Site
by a communication network for replicating block of transaction data logs, the
said Primary Site having processor configured to execute programmed
instructions for.
1) defining a block size of "n" transaction data logs;
2) replicating the said block of the transaction data logs from Primary Site to Secondary Site, when the block of "n" transactions is available or a timeout occurs;
3) marking the transactions of step (2) under replication as "partially complete" at the Primary Site;
4) receiving the said block of transaction data logs by Secondary Site;
5) processing either log write or transaction process of the block transaction data logs asynchronously by Secondary Site;
6) sending an acknowledgement to Primary Site by Secondary Site after processing the said block of transaction data logs; and
7) sending responses to one or more end users by Primary Site, after receiving the acknowledgement from the Secondary Site and subsequently committing all partially completed transactions.
20) The system of claim 19, wherein the Primary Site processes further transaction, in case of waiting for the acknowledgement from the Secondary Site.

21) The system of claim 19, wherein the Primary Site marks all the transactions that are processed as "partially complete" until their acknowledgement comes in from the Secondary Site.
22) The system of claim 19, wherein the Primary Site either rolls back the partially committed transactions or takes a business decision to allow for limited or full services to one or more end users without replication, in case of none of the acknowledgement is received within a timeout period.
23) The system of claim 19, wherein the communication network can be selected from the group of Wide area network (WAN), Local Area Network (LAN), Metropolitan Area Networks (MAN), internet, intranet, telecommunication network or TCP/IP.
24) The system of claim 19, wherein the performance of the said system depends on block size of the transaction data logs, bandwidth of the communication network between Primary Site and Secondary Site, propagation delay from Primary Site to Secondary Site, timeout parameter and number of outstanding messages between Primary Site and Secondary Site.
25) The system as claimed in all the precedent claims, wherein said system is a core banking or financial trading application.
26) A system and method substantially as herein described with reference to and as illustrated by the accompanying drawings.