Balancing Reliability with Innovation: Updates to the Core of our Expense Report Software

Today, we took Tallie expense report software offline for a major Saturday database maintenance window. I’d like to share with you what we did and the reasons why we did it.

Background

As an engineering team, we emphasize innovation. We seek to learn from the most cutting edge computer science techniques, adopting the appropriate ones for our size, underlying framework and functionality needs. At the same time, we are cognizant that even the most innovative financial technology must be stable and reliable for its customers. Tallie expense report software serves a critical business purpose — one we don’t take lightly.

Tallie’s stability and reliability is a commitment we stand behind; our consistently phenomenal uptime metrics are always available at status.tallie.com.

These potential cross-purposes create an interesting set of checks and balances on our engineering approach. To rationalize these forces, we have adopted a “leading edge, not bleeding edge” strategy, which I outlined a couple of years ago on our blog: Advancing SaaS Best Practices for the Expense Report Industry. We follow the latest trends in computer science, allowing time and space for the most innovative techniques to be proven, and adopting the best ideas shortly thereafter.

Sometimes, adopting the leading edge techniques requires some radical restructuring of underlying technologies. This restructuring can’t always be done in small increments. In some cases, attempting to do so would incur too much technical debt. In such cases, it is better to make a large change up-front than many small changes over time. Taking on changes of this scale requires methodical development, diligent testing and careful conversion on deployment. Which brings me to our project today…

Our Latest Release

Over the past year, we realized that our normalized database structure was becoming more of a liability than an asset (accounting reference intended). In order to achieve better performance for our current users and plan future growth, we needed to move to a more flattened structure. I’ll do my best to explain normalized and flattened structures below.

First, let me familiarize you with databases. A database consists of a series of tables, which you can think of as spreadsheets. In the case of expense report software, you might have a table of all company accounts, another table of all users and a table of all expenses in the system. In each table, a row is a single entry of data (a company, a user or an expense) and each column represents an attribute of that data set (such as name or merchant). Also, each row contains a unique identifier that allows other tables to reference each other. For example, we know which users belong to which customer by referencing these identifiers in each database.

Now, imagine each database table as a book on the shelf in your home. Under a flattened structure, they’re just books in your home that you will reference as needed. But under a normalized structure, there’s an extra book that serves like a card catalog for those books, holding common data from each book in a centralized location. Imagine for a minute that you have a few family members looking up information about books in your card catalog every few minutes. No big deal, right? Well, now imagine you’ve invited your entire neighborhood to use your card catalog all at once.

There’s a fight to get in, elbows are being thrown, and some are left to wait outside. That’s a much bigger deal, and it’s exactly what happens in an engineering context.

While a normalized database provided many data integrity benefits and represents a well-respected approach to computer science, the downsides of requiring the central table to be in use each time a sub-table was needed became a barrier to Tallie growth. Reorganizing our database gives us a faster, cleaner experience and lays the groundwork for future regional database scalability with server clusters located in regions closest to our customers, yielding even better performance.

What Can You Expect?

The desired outcome from this type of project is smooth performance — today and well into the future. We’ve worked long hours to make sure our underlying changes don’t negatively affect our customers and provide better performance at peak hours. Given the large scope of underlying changes, if you notice anything odd or out of the ordinary, please reach out immediately to our Product Expert team so we can resolve the issue for you. You can reach our Product Experts via live chat, phone (888.774.1118 x2) or email (support@usetallie.com).

Does this engineering work sound interesting to you? The Tallie Engineering Team is hiring! Check out our postings for Senior Software Engineer: Sustaining Hero, QA Automation Software Engineer, Senior/Lead Software Engineer: Cloud Services, DevOps – IT Operations Engineer and Senior Director of Software Development.

Leave a Reply

Your email address will not be published. Required fields are marked *