Ruby Video
Talks
Speakers
Events
Topics
Leaderboard
Sign in
Talks
Speakers
Events
Topics
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
"Hi, this is a friendly reminder you have an appt on 12/07, Thursday 2pm". How hard can building and scaling an Appointment Reminder system be? An average developer can build such proof of concept in under a day. But to scale it to sending to millions of patients a week, nobody in our team thought it'd take us to rewrite it the 4th time. From dealing performance pain and ever increasing complexity, we poured in countless hours to come up with the perfect design. We have a thing or two to share about solving a seemingly trivial problem.
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 the talk titled "Why Did We Rewrite Our Main Product Four Times?" at RubyConf 2021, Leon Hu, co-founder and CTO of Adoptable, shares the challenges experienced while building and scaling an appointment reminder system. The seemingly straightforward task of sending appointment reminders turned complex as the system had to cater to various customer demands and technical pitfalls. Hu discusses the evolution of their software through four iterations, highlighting vital lessons learned along the way. **Key Points:** - **Initial Development:** The original system allowed sending basic reminder texts with minimal code, but its simple architecture proved inadequate for real-world demands. - **Challenges Encountered:** As the user base grew, issues arose such as managing reminders for multiple family members sharing a phone number, supporting special instructions in messages, and adjusting to cancellations. - **Performance Bottlenecks:** As sales increased, the team faced performance issues due to inadequate monitoring and database strain, which necessitated a second rewrite focused on performance optimization. - **Shift to Event-Driven Architecture:** In the third rewrite, the system transitioned to an event-driven architecture to better process the influx of data and handle reminders efficiently, accommodating around half a million patient messages daily. - **Development Practices:** Hu emphasized the importance of test-driven development, proper performance monitoring tools, attention to memory use, and proactively identifying bottlenecks through various software tools. - **Continuous Learning:** The team learned the importance of scaling awareness, spreading job executions to reduce load, and leveraging read-only replicas for database tasks. **Conclusions and Takeaways:** - Address factors inhibiting system performance and scalability early in development to avoid extensive rewrites. - Invest in robust performance monitoring tools to preemptively identify and remedy potential issues. - Collaborate with business teams to ensure that software solutions meet client needs while remaining scalable. Hu concludes with a reminder of the value of teamwork in overcoming challenges and an invitation for developers to join their team at Doctor.com.
Suggest modifications
Cancel