Groupon's monolithic platform was struggling to support growth and feature development. They rewrote part of it using a Node.js service-oriented architecture with decoupled frontend applications and shared backend services. This allowed for faster development and improved performance, but also introduced increased testing needs and operational complexity compared to the monolithic approach.

1. I-Tier: Node.js at Groupon
Sean McCullough
@mcculloughsean
Enterprise Node.js Developer at Groupon

2. This Presentation is About...
• how Groupon's platform stopped working
• how we rewrote a part of it
• what went well and what didn't

3. Problems

4. Simple Start
• Monolithic Ruby on Rails app
• Sustained business through hyper-growth
• Small engineering team
• Simple product

5. Acquisitions
• CityDeal.de (Germany, most of EU)
• SoSata (India)
• Needish (South America)
Ran as separate platforms

6. One Monolithic Application

7. Actually, two separate monoliths

8. Move to Mobile
• ~50% of global transactions
• Streamlined user experience
• Mobile uses REST API

9. Two Facets of the Same Monolith

10. Two Facets X Two Monoliths

11. Business was Stuck
• Could not build features fast enough
• Wanted to build features worldwide
• Mobile and web lacked feature parity
• Could not change look and feel
• Difficult to internationalize

12. Platform was Broken
• Required cdn cached deal page
• Monolith was hard to scale
• Entire site would go down
• Couldn't support growth

13. The Plan

14. Start with the Frontend
• Unify global look and feel
• REST API already built for mobile
• Backend services are more complicated to unite

15. Design Goals
• Decouple teams
• Deploy apps on team schedule
• Allow for global design changes
• I18n/L13n
• Be small, do the minimum

18. Bakeoff
• Node
• MRI Ruby/Rails, MRI Ruby/Sinatra
• JRuby/Rails, Sinatra
• MRI Ruby + Sinatra + EM
• Java/Play, Java/Vertx
• Python+Twisted
• PHP

19. Why Node.js?
• Vibrant community
• NPM!
• Frontend developers know javascript
• Performant enough
• Easy scaling (process model)

20. Why Node.js Javascript?
• Front-end devs know Javascript
• Leverage existing knowledge on server

21. Stack
• CoffeeScript (hi haters!)
• Express
• Mustache & custom view engine
• Custom asset pipeline

22. Boundaries
• Apps only talk to REST API and Memcached
• Layout is in a separate application
• Shared common asset bundle

23. Design Goals
• Simple controllers
• Render from the server
• Skip fancy performance optimizations
• Make the API a bottleneck
• Resilience when services fail

24. Simple Design
module.exports =
main: ( {attributes, renderCallback} ) ->
# Presenter that sets the layout
view = presenters.page 'subscribe', attributes
# Grab the list of all the divisions
grouponAPI.fetch { endpoint: 'divisions' }, (err, {divisions}, details) ->
# If there’s an error, bail and pass the error along
return renderCallback err if err?
divisionsPresenter = presenters.divisions divisions, {
currentDivision: attributes.query?.division_p
}
view.set { divisions: divisionsPresenter }
render.pageHtml view, renderCallback

26. Subscribe Page
• Simple application
• Partial implementation
• Proved out the concept

28. Growing Pains
• Max sockets
• Breaking our infrastructure

30. New problems
• User authentication
• More service calls
• Complicated routing
• More traffic
• Share look and feel

33. grout
Switchboard for incoming requests to I-Tier
applications
• domain
• locale
• country
• experiments

34. grout
• groupon.com/deals/my-awesome-deal
• itier-deal-page-vip.snc1/deals/my-awesome-
deal
• groupon.de/browse/berlin
• itier-browse-page-vip.lup1/browse/berlin

35. grout
• Experiments between different applications on
the same URL
• Testing between alternative implementations
(including the legacy monoliths!)

38. gconfig
• Configuration as a service
• Some config can change on the fly
• Config can be promoted from uat -> staging ->
prod

40. Layout
• Distribute layout as library
• Use ESIs for top/bottom of page
• Apps are called through a “chrome service”
• Fetch templates from service

41. Layout Service
• Independent rollouts
• Changes can be shipped without re-deploying all
apps
• Easy to use in development

42. Layout Service
• Uses semantic versioning
• Roll forward with bug fixes
• Stay locked on a specific version
• Enable site-wide experiments

45. Rewrite All The Things!

46. Rewrite
• Get the whole company to move at once
• Supporting two platforms is hard
• Transition from June 2013 to September 1, 2013

47. Rewrite
• ~150 developers
• Global effort
• Feature freeze – A/B testing against mostly the
same features

48. What Went Well

49. It worked!

50. Webpages got faster

51. Sustained record traffic

53. What Didn't Go Well

54. Negatives of SOA
• Increased testing burden
• Tooling needs to catch up
• Increased operational overhead

55. Culture Problems
• Changed team workflow
• Teams are silos
• Code quality varies

56. Next Steps
• Better resiliency to outages
• Distributed tracing
• International (launching now)
• Open Source - Testium

57. tl;dr
• Kill web monolith
• Federated frontend
• Service oriented architecture
• grout
• gconfig
• Layout service

58. Thanks!
@mcculloughsean
empirejs 2014