2. Short Intro to Caching Evolution
Cache
In process caching
of Key->Value data
structure
Distribute Cache
Partitioned cache
nodes
IMDG
Partitioned system
of record
In Memory
Application Platform
Collocated IMDG and
Processing
Cache
Cache is good for repetitive data reads
But it is limited in capacity
It also doesn’t handle write-heavy scenarios
3. Short Intro to Caching Evolution
Cache
In process caching
of Key->Value data
structure
Distribute Cache
Partitioned cache
nodes
IMDG
Partitioned system
of record
In Memory
Application Platform
Collocated IMDG and
Processing
Distribute Cache
Allows you to distribute your cache over numerous machines so you get
Increased Capacity
But it doesn’t support write heavy scenarios
It’s also Limited to query by Id
What about the rest of your app? - Business logic & messaging??
4. Short Intro to Caching Evolution
Cache
In process caching
of Key->Value data
structure
Distribute Cache
Partitioned cache
nodes
IMDG
Partitioned system
of record
In Memory
Application Platform
Collocated IMDG and
Processing
IMDG solves these problems!
You get increased capacity
IMDG is also a System of Record with:
Query APIs
Optimized data access
Data integrity
It solves your write scalability problem
.
5. Short Intro to Caching Evolution
Cache
In process caching
of Key->Value data
structure
Distribute Cache
Partitioned cache
nodes
IMDG
Partitioned system
of record
In Memory
Application Platform
Collocated IMDG and
Processing
In Memory Application Platform
XAP for end to end scaling
Its an IMDG that hosts your Business
logic & has messaging services!
It Provides Parallel processing of data
You get linear scalability
You get high availability
How does XAP work?
6. Here’s What a Payment Authorization Process Looks Like
Payment
Authorization
Request
Basic Validation User Profile Check
Merchant
Profile Check
Payment
Authorization
Approved
7. Write the Payment Object to XAP
Cash Register
Application Payment
User payment Cluster
@SpaceId()
public Long getId() {
return id;
}
@SpaceRouting
public Long getUserId() {
return userId;
}
}
@SpaceIndex
public Long getCardId() {
return cardId;
}
}
The primary key of this object in the grid
The grid will use this attribute to route
the object to a particular partition
Payment object
A secondary index for query optimization
8. Write the Payment Object to XAP
Cash Register
Application
User payment Cluster
Payment
@SpaceId
public Long getId() {
return id;
}
@SpaceRouting
public Long getUserId() {
return userId;
}
@SpaceIndex
public Long getCardId() {
return cardId;
}
The primary key of this object in the grid
The grid will use this attribute to route
the object to a particular partition
Payment object
A Secondary index for query optimization
9. Write the Payment Object to XAP
Cash Register
Application
User payment Cluster
Payment
Index
@SpaceId
public Long getId() {
return id;
}
@SpaceRouting
public Long getUserId() {
return userId;
}
@SpaceIndex
public Long getCardId() {
return cardId;
}
The primary key of this object in the grid
The grid will use this attribute to route
the object to a particular partition
Payment object
A Secondary index for query optimization
Writing the event into the gridRouting to right partition – content-based routing by user IDReplicated synchronously to the partition’s hot backup
Easily indexing properties using annotations/metadata
co-location of the user with its cards and transactions – ensures affinity
Entry written to the space is handled implicitly as joining a queue, and creating a consumer to process entries from the queueConsumer is a simple Java class with some annotations which needs to define: (1) event template - which events are of interest(2) event handler - How to handle the eventsWhich entries are of interest? Easily defined as a simple method with @EventTemplate annotation and using a SQL query
Event handler easily created by annotating the methodIn the payment processing example – needs to validate that (a) credit card is OK and (b) create payment authorization state object for the subsequent validation phase
Compare current payment against user profileAll user’s card and payment info is available found with the user on same partition (thanks to our routing policy)Simple change API for inline property updatesExample of simple template-based queries
We’ll use remote distributed async task dispatch to perform this validationFirst the consumer fetches the VendorPaymentMsg, then it creates a task to make the validation
On our system architecture we create a separate vendors cluster (space) to enable vendor profiling on single partitionThe task is dispatched from our user’s node on the the payment cluster to the right node on the vendor cluster based on our content-based routing policy (based on the merchant ID)
In order to validate vendor all merchant’s deals are fetched and profiled, to assure this deal matches and no fraud
Once calculation is completed the result is asynchronously returned from the task back to the caller node (callback to the payment cluster node)Async invocation uses enhanced version of the standard Java Async API (Future).Again we use Change API to update the PaymentAuthorization.vendorCheck status flag
Fetch all PaymentAuthorization that completed initial validation (status=New) and that passed both userCheck and vendorCheck (the 2 ‘true’ values)And update the status to ‘Done’
Fetch all PaymentAuthorization that completed initial validation (status=New) and that passed both userCheck and vendorCheck (the 2 ‘true’ values)And update the status to ‘Closed’