How Argentina Pays Its Bills: 19 Million Cash Transactions a Month on Unreliable Networks with Pivotal GemFire and Spring

January 14, 2014 Adam Bloom

header-graphic-spring-gemfire-GIRE-rapipago-case-study-q-aPivotal GemFire allows GIRE to share transaction data and business rules across thousands of distributed systems where networks are unreliable. This gives GIRE executives a near real-time view of operations and a significant advantage over the prior method of nightly batch processing.

For this article, we had the opportunity and good fortune of having a Q&A dialogue with Gustavo Valdez, who is responsible for architecture and development at GIRE. If you haven’t heard of GIRE, they are the leading financial services company and the largest processor of electronic bills in Argentina. Visitors to just about any part of the country would likely to run into their most well-known brand, Rapipago. With over 2,600 branches, 4,000 kiosk-based points of sale, and a huge call center, Rapipago is part of GIRE’s business of providing billing, collection, payment, and transaction processing services.

Rapipago-GemFire-01

Could you explain what Rapipago does for consumers?

To put it simply, consumers visit our locations to pay their bills. Rapipago supports payments between 1200+ companies and their consumers—around 19 million transactions per month. Rapipago’s card, check, and cash-based transactions ultimately collect money on behalf of cell phone companies, automotive, banking, energy, gas, water, insurance, cable, credit cards, schools, municipalities, tourism operators, and more.

From a business perspective, why did GIRE choose to deploy Pivotal GemFire?

The biggest problem GemFire has helped us solve has to do with unreliable network connectivity. This limited our ability to report on the business operations and take certain actions. In our network, we collect money from 6 AM until 9 PM, depending on the region. Before GemFire, we had to wait until the next day to have visibility into how our network is collecting money. The previous system would process batch files each night. Our management team could only see transactions after a day’s time passed. In addition, many locations have unreliable network connections that make it harder to get a current view of the information.

With GemFire, we can see the information in real-time, even if there is an unreliable network. The data is synced 24 x 7 as the network allows. Now, we have a much more accurate view of the cash at each location. From an operations perspective, having a better picture of each payment point throughout the day means we can now decide to do things like send an armed vehicle to take cash off the street when large sums of money start to accumulate.

Could you share a high level view of your GemFire data architecture?

Sure. There are three key ways GemFire helps to manage the data to accomplish our business goals.

In each Kiosk, transactions are captured in a local GemFire instance. GemFire also places the transactions in a shared branch region. This way, we can share information between kiosks within a branch. For those that aren’t familiar, regions are the core building block of GemFire. Regions organize the data and are what you do puts, gets, and queries against. Regions can also be configured various ways. For example, they can be configured as local, distributed, or partitioned. As well, they can be set up as server, client, or peer regions.

In each branch, we have a GemFire peer-to-peer topology set up—a branch’s kiosks are part of a distributed system. Before GemFire, business rules were on the server side, and the system had to be online for the rules to run. With GemFire’s P2P topology, we have those rules running in each kiosk, and they can be executed when the server is offline.

The kiosks also place information on the GemFire WAN gateway to synchronize information to the central data center. With the WAN gateway, a returning network connection allows us to synchronize with the data center’s master database. When we don’t have internet connection to our central datacenter, we store all the transactions in the gateway’s queue. This is how we get a near real-time view of the entire network in a central place.

Can you explain more about how GemFire handles the WAN synchronization?

Yes. This is the key function that allows us to have up to date information and deal with lost network connections. We use the WAN gateway to synchronize transactions between kiosks and our data center. GemFire’s WAN gateway allows us to loosely couple multiple, independent GemFire systems. So, each of our kiosks has it’s own GemFire instance and region data is shared with the central GemFire instance via the WAN gateway. If communications between sites fail or become slow, the systems still run independently, and persistent queues operate for messaging between sites.

We also heard you used the Spring Framework on this project. Could you tell us about it?

We have actually been using Spring since 2007. We started using it to increase the quality of our development and reduce the time it took to deploy new functionality. As a financial services company, quality is critical because we track financial transactions. If our system has bugs, issues, or downtime, revenue can stop coming in. We use Spring for test-driven development as well as using Spring Data GemFire.

Is there an example of how you use Spring for test-driven development?

Test driven development helps us improve our designs and helps us automate unit tests. For example, we had to redesign our architecture. We changed from online mode to an asynchronous model with GemFire. Spring helped us mock all the new asynchronous services in the client, especially those involved with server data synchronization. This helped us improve the quality of development and testing overall.

What about GemFire, is there an example of how you use Spring with GemFire?

With GemFire, we use Spring Data. The Spring Data project gives us an easier way to manage GemFire. It was our first time using GemFire, and Spring Data helped us move faster. We would have had to spend a lot more time integrating GemFire if it wasn’t for Spring. Spring also helped us simplify the configuration. It saved us a lot of time and energy.

About Gustavo Valdez:

Mr. Valdez graduated with a bachelor’s degree from the Universidad de Palermo at Buenos Aires, Argentina. He started work as a software developer at the age of 17. In 2005, he started working at Gire S.A. as senior software developer. He is now Chief of Architecture and Development. Outside of work, he spends his time with his family and friends, plays football, enjoys video games, and listens to Pearl Jam.

For more information on Pivotal GemFire or Spring:

About the Author

Biography

Previous
Visualizing Garbage Collection by Pat Shaughnessy
Visualizing Garbage Collection by Pat Shaughnessy

Visualizing Garbage Collection in Rubinius, JRuby and Ruby 2.0 Watch live streaming video from pivotallabs...

Next
Why Retailers Should Stop Neglecting Tablets
Why Retailers Should Stop Neglecting Tablets

Less than a year ago, most analysts were recommending that mobile solutions be built strictly for smartphon...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!