Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
The Braintree Payment Gateway dates to 2008, and was built as a "monorail" -- a monolithic rails application that does everything. Over time, outward-facing features had to be built into it rather than as separate services because identity management, authorization, and authentication were tightly coupled to the rest of the application. Last year, we decided to fix that. We built a new, modern Rails API app, and I'll discuss the many differences from the old platform and why we decided to stick with rails. We also used some nontraditional methods such as running reads and writes through both applications to give us confidence in the new code and help us find missing test coverage. I'll talk about what we learned, what went well and poorly, and how we eventually switched over and split the two applications' databases without downtime.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In this presentation, Adam Forsyth, a software engineer and Community Lead at Braintree Payments, discusses the process of decomposing a highly available Rails application, specifically the Braintree Payment Gateway. Initially built as a monolith in 2008 with Rails 2.1, the application became increasingly difficult to manage as it grew over time. Forsyth shares insights on modernizing their architecture by extracting services and making their Rails application more modular. Key points covered in the talk include: - **Background on Braintree Gateway:** The app had grown to encompass 100,000 lines of code with poorly separated features, necessitating a decomposition approach to create more agile, independently deployable services. - **Development Strategy:** Forsyth highlights the high risk involved in the project, stressing the importance of safely transitioning to new code without causing downtime or breaking API authentication. They took a deliberate approach, incorporating modern Rails features and methodologies such as Test-Driven Development (TDD) and code review practices. - **Technical Modernization:** The new app was built from the ground up with Rails 4, utilizing ActiveModel serializers, OJ for faster JSON serialization, and addressing performance issues, such as dynamic endpoint calls and database connection overhead. - **Service Transition and Double Writing:** Forsyth discusses a critical technique where the old and new apps shared the same database during transition, allowing both to validate state integrity through double-writing practices, which improved confidence in new code's functionality. - **Database Separation:** Ultimately, a major challenge arose in splitting the databases without downtime. Forsyth explains methods to achieve this, such as utilizing a read-on mode during database dumps to avoid service interruptions, and ensuring other non-critical endpoints functioned properly. Overall, the session emphasizes the importance of modernization, safe transition practices, and strategic planning in the context of evolving legacy systems into more flexible architectures.
Suggest modifications
Cancel
