Why Did We Rewrite Our Main Product Four Times?
summary
A reminder system that began as 15 lines of code ends up rewrote four times because scaling and edge cases break naive models; the team moves from simple Rails + SMS (twilio) to solving 30 scheduling corner cases, memory fragmentation and DB load, hitting half a million messages a day, then adopts event-driven architecture, scattering jobs, switching allocators (je malek), adding datadock, pg hero, sidekick, typhoids and AnyCable to make the system fast, observable and reliable.
AI-written summary · about
chapters (6)
- 0:00Start
- 12:49Background Jobs
- 13:24Reasons To Pay Attention to Your Outbound Api Requests
- 16:13Conclusions
- 16:49Tips
- 17:37Hiring
related talks
32mRefactoring Legacy Apps with APIs and Messages
01h 01mMicroservices Gone Wrong
43mOld code doesn't stink - Refactor or Rewrite
30mMonolith-ifying perfectly good microservices
10mMicroservices, Messaging, and Failure: How Simplifying Our Architecture Saved Us
29mA 4-Pack Of Big Lightning Talks
29mHacking Development Culture: Treating Developers As People
44mMo' Jobs Mo' Problems: Lessons Learned Scaling to Millions of Jobs an Hour