Pablo Díaz Ogni

During my first years with Jampp, I developed a real-time bidding application that needed to respond to requests as quickly as humanly possible.

Jampp's main business involves buying programmatic ads for clients who are trying to reach a receptive audience that will then install and use the app.

This system receives requests from ad exchanges such as MoPub or Google Adx. For each request, it has to quickly decide whether to bid and which of its clients' ads to use. It is written with Python and Tornado and optimized with Cython. Every database access instance must be cached, so it won't bid on the first requests until all the data needed is cached.

My tasks involved adding features, profiling the system to find low-hanging fruits that can be improved, writing tests, deploying, monitoring, and handling incidents.

This library was created to send messages from the bidders' instances to another system, which creates predictive models using machine learning to optimize bidding.

The library consists of three parts:
• Proxy/Main: This is the connection point for the publisher and the subscribers. It sends the client-requested filters to the publishers and forwards messages from all the publishers to all the connected subscribers.
• Publishers: This was installed on the system to generate messages. It applies filters and sends messages through the proxy to the correct clients.
• Clients: This section asks for specific messages (using filters) and receives them.

This library is intended to be used on streaming processing platforms; given the Pub/Sub messaging system, it could generate misses (in practice, it doesn't happen) but is oriented to process high volumes of traffic, so the misses won't make a real difference.

Designed, developed, and implemented the new scalable data architecture that is used by all of Jampp's applications.

We migrated from PostgreSQL and MySQL databases to a new architecture that can be scaled up or down depending on the business needs. This was implemented using Python and ZeroMQ to receive messages and send them to Amazon Kinesis. Then, using AWS Lambda, Redis, and DynamoDB, the messages were related to each other in a transaction and later stored in Amazon S3. Then, another consumer sends the raw data to S3 to be later queried in an Amazon EMR cluster using Presto.

The second part of this project was performing the aggregation, reading directly from the Kinesis streams instead of using the relational tables from PostgreSQL. For all of the custom applications, we needed to build them in the middle of the chain, written in Python and (almost) fully unit tested.

Created an administration system for a resort with around 40 apartment units in Las Gaviotas, Buenos Aires.

The system manages the rental dates, calculates the fees for the agency, and generates reports. I used Java, Swing, and MySQL and created a small PHP-based login site for apartment owners.