Background

ZenPayroll is on a mission to help small business owners succeed by providing a simple and intuitive way to pay and appreciate their employees. We automate the complexities of tax payments and form filings and let small business owners focus on running their business. We currently service over 10,000 companies across the country and we are processing billions of dollars in annual payroll.

I joined ZenPayroll almost three years ago as the first engineering hire, and I currently lead the engineering team that keeps our clients compliant and builds tools to make sure our customer care team can do their job efficiently. Before joining ZenPayroll, I spent a year working with Pivotal labs doing Ruby on Rails consulting. Prior to that I was in a completely different industry and worked at a nuclear power plant after finishing my degree in electrical engineering.

Architecture

Our basic stack is Ruby on Rails and MySQL. We originally chose Rails because of the speed at which we could get our app up and running, and it is still working out great for us. We also use AWS services extensively in combination with Chef, having recently migrated to AWS from Rackspace. On the front end, most of our site is using Backbone, but we’ve been moving more and more to ReactJS.

Background processing is an integral piece to our system, and we have built a robust out-of-band infrastructure using Sidekiq Pro. A lot is happening behind the scenes and running payroll is just the beginning of the process. Throughout the day, payrolls are created, contractors are paid, bank accounts are verified via test transactions, and reversals are processed. It’s critical to our system to ensure all these actions are properly accounted for. Every time one of these actions is taken, we create bank transactions (via ACH) that tell our bank where money should be moved.

Timing is critical when paying employees, so we adhere to a strict schedule when communicating with our bank. At periodic intervals throughout the day, we batch these transactions by type, and consolidate them into files that the bank can process. Before our evening deadline, we upload all files created throughout the day to the bank so employees will be paid out the following day. The last part of the daily process requires us to confirm acknowledgement files provided from the bank and reconcile any discrepancies.

Most of the time, that is all we need to make sure our customers are properly taken care of, but occasionally bank transactions fail due to incorrect bank numbers or insufficient funds. If a transaction is unsuccessful, our bank sends us a response for the transaction and an associated error code, usually 2-3 days later. Every morning we download those files, stop any pending payments, and contact the administrator of the account to resolve the issue.

Sidekiq has been a great tool for us to robustly support our customers by allowing us to gracefully handle errors and highly parallelize our processing to scale with us as we grow.

Upcoming Architecture Changes

ZenPayroll is at a really exciting point right now, because the company and our customer base is growing so rapidly. In order to accommodate this growing user base as well as our expanding product vision, we’re currently in the process of architecting a system that can scale robustly. People depend on us for their livelihood, and we take that trust very seriously.

At a high level, we’re moving towards a service-oriented architecture (SOA). Currently our fraud and balance tracking systems are separated out into services, and we’ll be building out additional services in the coming months. More specifically, we’re in the middle of defining how these services will communicate with each other. We evaluated a handful of message-queuing systems and ultimately selected AWS’s SQS/SNS service. We’ve also been experimenting with Grape and have had a lot of success so far using it for our internal APIs. Grape makes it easy to implement our internal APIs, and we’re writing a gem, dubbed GrapeEater, that will make it easy to communicate with Grape APIs. GrapeEater consumes a Grape API and programmatically generates and maintains a client gem for that API. On startup, the client gem dynamically generates a request method for each endpoint from JSON swagger documentation generated for the Grape API. We hope to open source GrapeEater very soon!

So far, all of our services have also been in Rails, which allows developers to move around code bases easily. We haven’t yet found a good use case to use something else - but that could always change.

On the frontend, we’re transitioning to using ReactJS more heavily. Our original customer dashboard is a thick Backbone app that consumes our Rails API. Our Backbone paradigm has been effective over the past two years, but as we have added more and more features, we have found that our views have started to become a little unmanageable. While Backbone has provided us with great data management and API interaction, we found that we need a more powerful tool for creating UI.

We're adopting ReactJS due to its declarative nature of creating user experiences, high performance, and ease of integration with our existing Backbone models and collections. We use Reflux to bolster our frontend architecture, as well as ImmutableJS to more easily reason about our data structures. Our new React paradigm has been a breath of new life into both our frontend development patterns and UI.

Scaling Challenges

One of the most intensive times for payroll is during the end of the quarter (and especially the end of the year!). We’re doing extensive number crunching to make sure everyone’s taxes are correct and paid when they should. We also generate tens of thousands of form PDFs (using Prawn) to file on behalf of our clients and their employees and contractors.

This is where we’ve really been able to reap the benefits of Sidekiq. We’ve moved from a collection of rake tasks to aggressively parallelizing these jobs with hundreds of sidekiq workers. Our end-of-quarter reconciliation process used to take a few hours (with a fraction of the companies). Now we can process in a matter of minutes!

Engineering Team

Currently we’re at 20 engineers, split across 5 teams - with focuses on security, fraud, state expansion, compliance tools, and product features. We believe that small, focused, autonomous teams are the most effective. At the same time, ZenPayroll has an incredibly collaborative culture, and there are many cross-team opportunities. Most of our team is comfortable working through the whole stack, and if they’re not, we’re helping them learn.

We recently announced our Series B and #1 Best Place to work in the Bay Area (for 50-99 employees), and we’re growing fast! We’re hiring for pretty much all positions currently, and in particular are looking for strong engineers who are passionate about our mission to support small businesses. We’d love to hear from you!





Verified by
Favorite
5
Views
1279
Favorite
Views
1279