E-Commerce and MongoDB at Backcountry.com
Download as PPTX, PDF2 likes2,312 views
The talk will describe the results we got by adopting MongoDB in key areas of our business. Backcountry.com is a midsize company in constant evolution looking for growth in a extremely competitive ecosystem. We try to be agile and target fast prototyping and data-based decisions. Our dev stack used to heavily rely on Postgres and Oracle, but in a short period of time we were able to introduce MongoDB in a key set of applications and we've seen positive results. We're less dependent on monolithic applications and we're progressively moving to Microservices. By choosing MongoDB as one of our main technologies, our dev teams became more productive as well as mature. They see beyond relational approaches and explore more options to tackle different problems.
Ad
More Related Content
What's hot (20)
Similar to E-Commerce and MongoDB at Backcountry.com (20)
Ad
More from MongoDB (20)
![MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]](https://cdn.slidesharecdn.com/ss_thumbnails/315pminfosysfinalsfoversionvocalpart1-200120221508-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
E-Commerce and MongoDB at Backcountry.com
- 1. MONGODB AT BACKCOUNTRY.COM Gustavo Leiva. Engineering Manager @gustavoleiva
- 2. Keypoints ● MongoDB and E-Commerce ● Technology adoption ● Microservices ● Decoupling
- 3. WHO WE ARE
- 4. E-Commerce ● Authority, expertise and guidance on outdoor gear, since 1996. ● Started business with open source monolith platform(Perl and PostgreSQL). ● Moved backcountry.com front end to a monolith proprietary enterprise commerce solution on 2012. ● On going effort towards a microservices architecture.
- 5. How we work ● Distributed teams: United States (Park City, Portland), Costa Rica(San José). ● Agile. ● Believe in innovation. ● Inspire others. ● Prepare for growth. ● Build technology when it makes sense.
- 6. IT Transformation 2000 2012 2015 Perl, PostgreSQL Oracle ATG, Java NoSQL, JVM languages, Node, Automation and more web frameworks.
- 7. IT Transformation ● Smaller teams. ● Independent. ● Currently working on increasing automation. ● Organically moving to a microservices architecture. ● Current transition seems to reflect the Conway’s law.
- 9. The pipeline Socialize Partner Guide Buy On Board Promote Sell Fulfill Follow up
- 10. Why MongoDB? ● Simple. ● Flexible. ● Easy to learn. (Quick ramp up with MongoDB U: NodeJS, Java Development) ● Cost effective. ● Fit the use case. ● Our engineers liked it. ● A sense of relief from our former technologies. ● Thumbs up from sys admins and engineers. Buy On Board Promote Sell Fulfill Follow up
- 11. Adoption of MongoDB ● Started as part of a prototype application(MEAN stack). ● Suggest and assign work to writers whenever new product content needed to be written. ● Events would be stored and retrieved from MongoDB. ● Still functioning as an active component of content creation process. ● Reduce time where writers are idle. Buy On Board Promote Sell Fulfill Follow up
- 12. PROMOTE
- 13. The Hub HUB Buy On Board Promote Sell Fulfill Follow up
- 14. The Hub ● Notify of changes in product, price and inventory. ● Single source of truth for systems requesting data. ● Consolidates data that used to be queried from the legacy platform. ● Step towards decoupling and scalability. Buy On Board Promote Sell Fulfill Follow up
- 15. MongoDB and the Hub APIProduct Inventory Price Topics Buy On Board Promote Sell Fulfill Follow up
- 16. Feeds, the Hub and MongoDB HUB 40% of revenue driven by marketing channels Buy On Board Promote Sell Fulfill Follow up
- 17. Merchandising, Email Buy On Board Promote Sell Fulfill Follow up
- 18. Merchandising, Email ● Removed the need of an engineering team to implement new emails. ● Email objects are stored in MongoDB. ● Eventually sent to the third party provider that takes care of sending the actual email. ● Provided visibility into email traffic activity. ● Extended to cover a generic customer notification concept. Buy On Board Promote Sell Fulfill Follow up
- 19. Merchandising, Email, Data Buy On Board Promote Sell Fulfill Follow up
- 20. SELL
- 21. Front End Commerce Platform Transformation Buy On Board Promote Sell Fulfill Follow up Product Community Cart & Checkout Targeting Users/Tagging/ etc Oracle ● At the time of adoption of enterprise commerce platform, 2012. ● Rigid release process. ● Felt the pain of a replatform. Technical debt. ● Slowdown on business development.
- 22. Product ● Created API(Scala, Play) to expose product, category and brand content on the site. ● MongoDB as product store. Solr as search engine. ● Serves 60% of sites traffic. Buy On Board Promote Sell Fulfill Follow up Product Community Targeting Cart & Checkout Users/Tagging/ etc OracleAPI
- 23. Product Buy On Board Promote Sell Fulfill Follow up ● products ● categories ● brands
- 24. Community ● Created API(Play, Scala) to store community contributions: reviews, images, videos, questions, answers. ● Aggregation pipeline used to optimize product contributions wall and customer’s profile wall. ● Opened potential to extend functionality. ● Removed OOTB(ORM) repository layer queries that impacted performance. Buy On Board Promote Sell Fulfill Follow up Product Community Targeting Cart & Checkout Users/Tagging/ etc OracleAPI
- 25. Community Buy On Board Promote Sell Fulfill Follow up ● user ● content
- 26. Targeting ● Targeting engine from commerce platform exposed as a service. ● Found under utilized personalization capabilities. ● Performance hit from existing overhead to resolve a problem that was simple in the majority of cases. Buy On Board Promote Sell Fulfill Follow up Product Community Targeting Cart & Checkout Users/Tagging/ etc OracleAPI
- 27. MongoDB and the FE Commerce Platform Product Promotional Content Community Buy On Board Promote Sell Fulfill Follow up
- 28. Differentiate, Partner ● Experience provided enough confidence to start adding differentiation features. ● Fit data by profile and community review. ● UI aggregation layer for the mobile app. ● Potential for Partnerships. Buy On Board Promote Sell Fulfill Follow up
- 29. Partner ● MongoDB as storage and aggregator of strava data(NodeJS). ● Assign credits based on historical information of activities in a time range. Buy On Board Promote Sell Fulfill Follow up
- 30. Partner Buy On Board Promote Sell Fulfill Follow up Sync up(10K) New accounts 2K Day 1
- 32. Towards a cost effective commerce model ● Effort on decoupling makes the company less dependant on a commerce solution. ● Use the commerce platform for cart & checkout operations, decouple the other pieces. ● Non cart and checkout operations can be fully executed outside the commerce platform. ● Change pricing model to charge by requests rather than cores, better fit for scalability. Buy On Board Promote Sell Fulfill Follow up
- 33. Towards a cost effective commerce model ● Adding more data centers would have significantly increased operational costs in terms of commerce platform licensing. ● MongoDB reliant APIs plus work on caching strategies(Varnish, Redis) allow us to grow in terms of traffic, without hitting our pricing model requests threshold. ● We’ll be able to use the commerce platform for what it does best. Buy On Board Promote Sell Fulfill Follow up
- 34. Q4 at Backcountry.com Buy On Board Promote Sell Fulfill Follow up Jan Dec $
- 35. Q4 at Backcountry.com, 2013 ● Struggled with stability, overhead with monolith enterprise solution. ● Delegated too many tasks to the commerce platform. ● Engineering spent long hours trying to fix things. ● Q4 is the true final test for any technology at backcountry.com Buy On Board Promote Sell Fulfill Follow up
- 36. Q4 at Backcountry.com, 2014 ● Commerce platform took less tasks. ● It was the first Q4 of several MongoDB reliant APIs. ● No major issues were presented. ● Best Q4 remembered, in terms of stability and Q4 preparation work. ● Company hit the revenue goal. Buy On Board Promote Sell Fulfill Follow up
- 37. Q4 at Backcountry.com, 2014 Buy On Board Promote Sell Fulfill Follow up
- 38. CONCLUSIONS
- 39. Challenges ● Keeping schemas clean. 20% Backlog. ● Making sure the use case is a fit. Architectural Review Board. ● Ownership: Owning the stack vs DBA delegation. ● Risk Management. ● Business traction.
- 40. What worked ● Fit a variety of use cases. ● Served a diverse amount of traffic. ● Allowed fast adoption and quick development. ● Key technology on the decoupling effort and the strategy around being cost effective. ● Services on top of MongoDB. ● Transparency on DB status with MMS.
- 41. THANK YOU
Editor's Notes
- #11: setup fast