Embracing the Monolith in Small Teams
summary
Argument for a monolith focuses on specifics: small cross‑disciplinary teams use Django + IPython + Postgres plus Segment and Stitch to centralize data, run exploration in the same codebase, and push a slash report in Slack for nontechnical staff. A deployed predictive model exists as an extracted service but initially causes a latency spike that triggers 2am alerts; analytics speed jumps from ~200s on Postgres to ~4s on Redshift; product claims users sleep ~54 minutes more on average, and those metrics guide choices.
AI-written summary · about
chapters (12)
- 0:00Monoliths in small teams
- 5:09Slow product cycles
- 13:17Business vs technical balance
- 18:11Monolith vs microservices trade-offs
- 22:05Django for monoliths
- 24:57Reusing code for data exploration
- 27:24Django ORM with pandas
- 29:09Free instrumentation benefits
- 30:11Self-serve analytics
- 33:03Slack data delivery
- 35:08Python and AWS scrappy
- 35:52Q&A
related talks
47mBuilding Scalable Web Apps
47mReal World Django Q&A
29mSwiss Army Django: Small Footprint ETL
26mBuilding a RESTful real-time analytics system with Pyramid
25mA microservices architecture with Python and Docker containers
29mFrom rocks to a hammer when and how to change your company's analytical tools
41mProduction Django: Building a Highly Scalable, Secure Django Site
45mBuilding an Analytics Platform