Mesoservices
summary
Picnic describes a deliberate move away from fine-grained microservices toward “mesoservices”: fewer independently deployed services, a weekly release process instead of full continuous deployment, and a constrained stack (primarily Java Spring + MongoDB with ElasticSearch). Core real systems built include warehouse management, vehicle routing and distribution planning running on AWS + Elastic Beanstalk, with REST and messaging between services, local caches and eventual consistency. Team size is around 25 engineers; the approach reduces integration overhead and speeds time‑to‑market while postponing full microservice granularity.
AI-written summary · about
chapters (14)
- 0:00Introduction and background
- 2:01Engineering vs operations trade-offs
- 5:33Picnic’s business model
- 8:25Picnic’s backend services
- 12:15Why microservices appeal
- 13:42Picnic’s startup constraints
- 15:32Microservices challenges
- 18:24Team structure and tech stack
- 20:56Balancing growth and stability
- 23:24Future architecture vision
- 25:55Picnic’s architectural journey
- 31:36Mesoservices approach
- 35:51When to split services
- 36:33Closing and Q&A
related talks
44mSo What are Microservices
48mChallenges in Implementing MicroServices
26mMicroservices
42mInnovating Faster with Micro-Service Architecture...
52mMicroservices: A Utopian Mystery
44mA Software Engineer's Journey Through Microservices Data Sharing
23mMicroservices – Sean Smith
23mMICROSERVICES ARCHITECTURE AS IF YOU MEANT IT