Groupon recently completed a year-long project to migrate its U.S. web traffic from a monolithic Ruby on Rails application to a new multi-application stack with substantial results. Groupon’s entire U.S. web frontend had been a single Rails codebase from its inception in 2008. The frontend codebase quickly grew large, which made it difficult to maintain and challenging to ship new features. As a solution to this gigantic monolith, we decided to re-architect the frontend by splitting it into small, independent and more manageable pieces. At the center of this project, we rebuilt each major section of the website as an independent application. We also rebuilt the infrastructure to make all the independent apps work together. Interaction Tier (I-Tier) was the result. Learn about how Groupon achieved this great architecture migration and the business results it is driving.

1. i-tier: breaking up the
monolith
sean mccullough
groupon engineering
@mcculloughsean

2. this presentation is about
4 how Groupon's software stopped
working
4 how we rewrote a part of it
4 what went well and what didn't

3. this presentation isn't about
4 node.js
4 javascript

4. Problems

5. simple start
4 monolithic Ruby on Rails app
4 sustained business through
hypergrowth
4 small engineering team
4 simple product

6. acquisitions
4 CityDeal.de (Germany, most of EU)
4 SoSata (India)
4 Needish (South America)
ran as separate platforms

7. new products
4 Goods
4 Getaways
4 Reserve

8. improvements
4 Smart Deals
4 Browse and Search
4 Rocketman

9. one monolithic application

10. actually, two separate monoliths

11. move to mobile
4 ~50% of global transactions
4 streamlined user experience
4 mobile uses REST API

12. two facets of the same monolith

13. two facets X two monoliths

14. business was stuck
4 could not build features fast enough
4 wanted to build features worldwide
4 mobile and web lacked feature parity
4 could not change look and feel

15. The Plan

16. start with the frontend
4 unify global look and feel
4 REST API already built for mobile
4 backend services are more complicated
to unite

17. design goals
4 decouple teams
4 deploy apps on team schedule
4 allow for global design changes
4 I18n/L13n
4 be small, do the minimum

20. bakeoff
4 Node
4 MRI Ruby/Rails, MRI Ruby/Sinatra
4 JRuby/Rails, Sinatra
4 MRI Ruby + Sinatra+EM
4 Java/Play, Java/Vertx
4 Python+Twisted
4 PHP

21. why node
4 vibrant community
4 NPM!
4 frontend developers know javascript
4 performant enough
4 easy scaling (process model)

23. simple design
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

24. boundaries
4 apps only talk to api and memcached
4 layout is in a separate application
4 shared common asset bundle

25. growing pains
4 max sockets
4 breaking our infrastructure

27. subscribe page
4 simple application
4 partial implementation
4 proved out the concept

29. new problems
4 user authentication
4 more service calls
4 complicated routing
4 more traffic
4 share look and feel

30. Part III -
Architecture

33. grout
switchboard for incoming requests to I-
Tier applications

34. grout
Route on:
4 domain
4 locale
4 country
4 experiments

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

36. grout
4 experiments between different
applications on the same URL
4 testing between alternative
implementations (including the legacy
monoliths!)

39. gconfig
configuration as a service
some config can change on the fly
config can be promoted from uat -> staging
-> prod

41. layout service
maintain consistent look and feel across
site

42. layout service options
4 distribute layout as library
4 use ESIs for top/bottom of page
4 apps are called through a “chrome
service”
4 fetch templates from service

43. layout service
chose a service
4 independent rollouts
4 changes can be shipped without
redploying all apps
4 easy to use in development

44. layout service
4 Uses semantic versioning
4 Roll forward with bug fixes
4 Stay locked on a specific version
4 Enable Site-Wide Experiments

47. Rewrite All The
Things!

48. rewrite
4 get the whole company to move at once
4 upporting two platforms is hard
4 as of June 2012 - move to I-Tier by
September 1st

49. rewrite
4 ~150 developers
4 global effort
4 feature freeze – A/B testing against
mostly the same features

50. it worked!

51. webpages got faster

52. sustained record traffic

54. what doesn't work
4 increased testing burden
4 tooling needs to catch up
4 increased operational overhead

55. culture problems
4 changed team workflow
4 teams are silos
4 code quality varies

56. next steps
4 streaming responses for better
performance
4 better resiliency to outages
4 distributed tracing
4 international (launching today!)
4 open source - testium

57. tl;dr
4 monolith
4 federated frontend
4 service oriented architecture
4 grout
4 gconfig
4 layout service

58. thanks!
sean mccullough
groupon engineering
@mcculloughsean