Modern transactional systems need to be fast, always available and constantly scale to meet the ever changing needs of the business. It is becoming increasingly commonplace for next generation e-commerce systems to demand double or single digit millisecond response times, for financial trading systems to incur maximum latencies in the order of microseconds and gaming and analytic engines to consumes hundreds of thousands of transactions a second. It is a common and tempting mistake to believe that we can meet the extreme needs of such systems by just replacing traditional disk based storage systems with in-memory data grids using traditional application architectures. Such an approach will take us only so far after which the system’s demands will once again overtake its capabilities. To truly meet the extreme needs of these systems and continue to scale as the demand scales, we need to think differently about how such systems are architected and employ modern techniques to unlock the full potential of memory oriented computing. This talk explains why and how. Join Girish Mutreja, CEO of Neeve Research and author of the X Platform as he discusses the above and provides a unique perspective into what’s different about memory oriented TP applications and how application architectures, particularly mission critical applications, need to adapt to the new world of memory oriented computing. Girish will outline the key architectural elements of TP applications and explain how they need to function in the world of memory oriented computing. He will delve into why such systems need to be architected as a marriage between messaging and data storage; why message routing and data gravity is of critical importance to these systems; how structured, in-memory state lends to extreme agility; how fault tolerance, load balancing, transaction processing and threading need to function in such systems; why architectural precepts such as transaction pipelining and agent oriented design are critical to reliability, performance and scalability. Girish will illustrate how these concepts have enabled enterprises such as MGM Resorts to transition to game changing, memory oriented architectures by leveraging the X Platform.

1. EXTREME TRANSACTION PROCESSING IN A
MEMORY-ORIENTED WORLD
GIRISH MUTREJA
See all the presentations from the In-Memory Computing
Summit at http://imcsummit.org

2. THE POWER OF IN-MEMORY COMPUTING
FAST!
SIMPLE
// create a new cart
Cart cart = Cart.create();
...
// add to the application's cart collection
carts.put(cart.getId(), order);
...
// update cart counter
stats.incrementNumCarts();
Memory

3. IN-MEMORY TRANSACTION PROCESSING
FAST!
SIMPLE
// create a new cart
Cart cart = Cart.create();
...
// add to the application's cart collection
carts.put(cart.getId(), order);
...
// update cart counter
stats.incrementNumCarts();
Memory
DURABLE
CONSISTENT

4. EXTREME TRANSACTION PROCESSING
Operate at Memory Speed
Without compromising simplicity, durability, consistency and s
By Using Memory Optimally with the Right Architecture

5. HOW “EXTREME” ARE WE TALKING HERE?
 Scale
 10s of millions of orders in application’s working set
 Scale linearly with the business
 Performance
 100s of thousands of order transactions a second
 Microseconds to low milliseconds processing times
 Reliability
 Zero message or data loss across network, process, machine or data center failures
 Agility
 Write pure Java treating memory as the disk

6. TRADITIONAL TP APPLICATION ARCHITECTURE
Relational Database
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(HTTP, JMS)
 Slow
 Complex
 Does not scale with size or
volume
 Synchronous
 Slow
 Poor Routing
(Choke Point!)
Wrong Scaling
Strategy
Slow
Durable
Consistent
Does Not Scale
Complex

7. LAUNCH DATA INTO MEMORY
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(HTTP, JMS)
 Better but still slower than
memory
 Simpler but still not pure domain
 Does not scale with size
 Synchronous
 Slow
 Poor Routing
(Choke Point!)
Wrong Scaling
Strategy
Slow
Durable
Consistent
Does Not Scale
Complex
In-Memory
Replicated

8. DATA GRAVITY (DATA STRIPING + SMART ROUTING)
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(Publish -
Subscribe)
 Better but still slower than
memory
 Simpler but still not pure domain
 Scales with size and volume
(Choke Point!)
Slow
Durable
Consistent
Scales
Complex
In-Memory Replicated + Partitioned
Smart Routing
(messaging traffic partitioned to align with data partitions)
Processing Swim-lanes

9. WHY STILL SLOW AND COMPLEX
 How Slow?
 Latency
 100s of milliseconds
 Throughput
 Very low with single pipe
 Few 1000s per second with high concurrency
 Why Still Slow?
 Remoting out of process
 Synchronous data management and stabilization
 Concurrent transactions are not cheap!
 Why Complex?
 Transaction Management still in business logic
 Thread management for concurrency (only way to scale)
 Data transformations due to lack of structured data models

10. TAKING IT TO THE NEXT LEVEL
Local Application State
 Application state fully in local memory
 Eliminate Remoting
 Performance
Multi-Agency & Transaction Pipelining
 All interactions with outside world is through messaging
 Inbound messages implicitly demarcate transactions
 Non-blocking stabilization
 Treat outbound messages as state
 Performance
 Consistency
 Simplicity
Single Threaded Business Logic  Eliminate concurrent state management
 Performance
 Simplicity
Structured State
 Support full language data model
 Code truly assumes memory is durable
 Performance
 Simplicity

11. TAKING IT TO THE NEXT LEVEL
Application + Data
Tier
(Business Logic
Transactional State
Reference Data)
Messaging
(Publish -
Subscribe)
Fast
Durable
Consistent
Scales
Simple
In Application Memory Replicated + Partitioned
Smart Routing
(messaging traffic partitioned to align with data partitions)
Processing Swim-lanes
 Operate at memory
speeds
 Plumbing free domain
 Scales with size and
volume
Application State
fully in Local
Memory
Single-Threaded
Dispatch
Pipelined
Stabilization
Pure
domain
code

12. NOW WHAT IS THE PERFORMANCE?
 How Fast?
 Latency
 100s of microseconds to low milliseconds
 Throughput
 100s of thousands of transactions per second
 Any issues?
 Jittery due to GC
 Still some work is needed for ultra-low latency

13. TAKING IT EXTREME
Eliminate Inter-Tier Transformations  Zero buffer copies between network and business logic
Eliminate Garbage  Object pre-allocation and recycling
 How Fast?
 Latency
 10s of microseconds
 No jitter
 Throughput
 100s of thousands of transactions per second

14. REAL LIFE USE CASES
 MGM Resorts International
 eCommerce Engine is authored on the X Platform
 10 services/26 agents comprise the eCommerce service suite
 Key metrics
 All state, reference and transactional fully in-memory: ~1TB of in-memory state
 Low 10s of millisecond catalogue/pricing update latency
 500ms (max) full 14 month dynamic pricing response time to website at upwards of 20tps
 Sub-second rate update to partner
 SSO storage engine authored on the X Platform
 Authored as a distributed, persistent, partitioned hash map
 Authored on X in 3 hours!
 <10ms response times @ 20k updates per second
 Bottleneck in messaging bus, X has plenty of more capacity

15. REAL LIFE USE CASES
 Tier 1 Investment Bank Wall Street
 X Platform foundation for all equities applications
 Key Metrics
 Application 1: 50-100k/sec sustained throughput
 Application 2: <100us client-market latency

16. IOT APPLICATION – EXTREME GEOFENCING
Location Event
Processors Intelligent Rule
Execution
Location Events
Mobile Vehicle Pool
Inferences
Decisions
Notifications
Performance
 400k
Transactions/sec
 1.7ms response time
 < 100 lines of code
 1 CPU Socket!
 Stock Hardware
Single Shard!

17. QUESTIONS
?