GIRE is a leading financial services company based in Buenos Aires, Argentina. They provide billing, collection, payment and transaction processing services via the web, call center, retail service centers, kiosks and an agent network that includes supermarkets, subways and other locations. Their key brand is Rapipago, one of the most well-known and popular services across all of Argentina. With over 2,600 branches in their collection network and 4,000 points of sale, Rapipago supports payments between 1,200+ companies and their consumers – around 19 million transactions per month. Rapipago’s card, check and cash-based transactions ultimately collect money on behalf of mobile phone, automotive, banking, energy, gas, water, insurance, credit card and cable companies, as well as schools, municipalities, tourism operators and more.
Nightly Batches and Unreliable Networks Limit Business Operations
Rapipago kiosks and branches collect money during the day and an earlier version of their system would deliver a batch file to be processed each night. Because of the delay with batch processing, their management team could see only transactions after a day’s time passed. The company wanted to move to an online architecture to support real-time processing and analysis. Additional challenges stemmed from the fact that the kiosk locations had unreliable Internet and telecommunications connectivity, but still needed to be able to collect money when network connections were down.
No Single, Real-Time View of Cash Poses Risks
As a collector of cash, part of the operations of Rapipago includes managing the cash on-hand at branches. Without a real-time system, the company didn’t have an accurate, current view of key metrics – like cash – and the information delay posed a risk to the business. For example, it wasn’t clear when to send an armed vehicle to take cash off the street at any given location. The GIRE leadership agreed that a real-time view would help them run the business better.
Pivotal GemFire Provides Near Real-Time Data over an Unreliable Network
Pivotal GemFire was incorporated into Rapipago’s Spring-based architecture and Gustavo Valdez, Chief of Architecture and Development at GIRE, shares the key design advantages, “Pivotal GemFire helped us solve a lot of problems. Most importantly, we can track and collect money at our 4,000+ kiosks and branches – even without a reliable Internet connection. GemFire provides the core data grid and a significant amount of related functionality to help us handle this unreliable network problem. With GemFire, management can see what is happening in real-time and apply business rules without delay.”
In each kiosk, transactions are captured in a local Pivotal GemFire instance that is part of three distributed models – P2P, Client/Server and WAN. As network connectivity allows, information is synchronized between kiosks, between kiosks and branches and between kiosks and the central data region hosted in a data center. GemFire also stores and distributes business rules between branch locations among other configuration parameters for the application.
Guarantees Data Synchronization as Network is Available
As the network comes and goes, Pivotal GemFire WAN gateways queue information to synchronize transactions and allow payment collection without a single point of failure for data, even if the network is down for days. Within the gateway configuration, nodes and queues pass acknowledgements back to guarantee delivery to the centralized data region for analysis. Additionally, the transactions are synced in optimized batches to avoid flooding the network. Valdez elaborates, “When we don’t have Internet connection to our central datacenter, we store all the transactions in the GemFire gateway’s queue. This is how we get a near real-time view of the entire network in a central place.”
Provides Reliable Persistence, Advanced Replication and High Availability
While all kiosks keep payments in memory, Pivotal GemFire also persists data regions to disk for recovery if a kiosk fails. The distributed architecture also supports high availability in an active-active state. While Rapipago’s system syncs to a centralized region, groups of kiosks are also replicated to local branch regions. GemFire allows replication to happen in parallel and reach a consistent state with an advanced model for configuring consistency and an ability to use different network paths. “Regions organize the data and are what you perform puts, gets and queries against. Regions can also be configured various ways. For example, they can be configured as local, distributed, or partitioned. They can also be set up as server, client, or peer regions,” Valdez explains.
Distributes and Supports Local Business Rules
“In each branch, we have a Pivotal GemFire peer-to-peer topology set up. Before GemFire, business rules were on the server side and the system had to be online for the rules to run,” notes Valdez. “With GemFire’s P2P topology, we have those rules running in each kiosk and they can be executed when the server is offline.” With this in place, all the kiosks within a branch can share business rules. GemFire supports these types of needs by colocating a peer-to-peer replicated data cache within an application’s memory or executing distributed functions on certain nodes and data regions.
With Pivotal GemFire’s rich feature-set running the distributed data grid, GIRE’s Rapipago has a platform that will allow them to meet future business needs, operate a real-time business operation within unreliable networks and scale with growth. According to Valdez, “Pivotal GemFire is not only a backbone to the Rapipago application, it is a backbone to our business. It has helped us save time and money while reducing risk and improving our application performance. We can better manage business because of GemFire. Looking back, I can’t imagine us developing significant pieces of our data tier from scratch when such a proven, well-supported data grid like GemFire is available to us.”