Building a globalized, customer facing e-commerce product, powered by micro-services (#21 Athens Ruby Meetup)

Building a globalized,
customer facing e-commerce product,
powered by micro-services

Hello!
We are team e-Travel
We are here to share what 10 years of trying
to go global has taught us

Tasos Latsas
@tlatsas
1+ years in e-Travel:
◦ ~1 year doing ruby/web development
◦ ~2 years doing python/web development
◦ ~6 years doing random stuff with linux
systems/services/distros

Nikos Dimitrakopoulos
@nikosd
6 years in e-Travel & Fraudpointer:
◦ ~1 year C#/web development
◦ ~4 years ruby/web development
◦ For the last year “disarmed” from coding,
leading the Product team
Ruby fanboy since 2004 :)

Outline
1. Timeline: Challenges + Solutions over
time
2. Biggest mistakes
3. What’s next

LONG TIME AGO...
(that few know of, or remember)

Long time ago… (2004 - 2008)
That at some point became two sites
With multiple brandings and multiple languages
There was a simple ASP.Net site...

Long time ago… (2004 - 2008)
But they were actually different sites
◦ Using the same codebase
◦ But different deployments

Long time ago… (2004 - 2008)
Each site was hardwired to a specific
branding, language and “market”

Long time ago… (2004 - 2008)
◦ For example pamediakopes.gr
▫ Was in Greek
▫ With “pamediakopes.gr” branding
▫ And was targeted to the Greek and
Cyprus markets

Long time ago… (2004 - 2008)
◦ For example pamediakopes.gr
▫ Was in Greek
▫ With “pamediakopes.gr” branding
▫ And was targeted to the Greek and
Cyprus markets
◦ And fantasticgreece.com/de
▫ Was in German
▫ With “fantasticgreece.com” branding
▫ And was targeted to the German
market

Medieval ages (2008 - 2011)
(that some have heard about but few remember)

First wave of new markets

Translations automation & management
▫ Scripts & tools for extraction of keys
(Gettext)
▫ Standardized po files (Gettext) as
translation dictionaries
▫ Transifex to the rescue as a
management platform!

Each new market was a major project (year+)
◦ Either as a new sub-site (for example
“airtickets24.com/ru”)
◦ Or as a brand new, stand-alone domain
(for example trip.ru)

l10n and i18n still an afterthought and mostly
just translations

At the same time complexity exploded
▫ New products
▫ Smarter products
▫ More features
▫ New platforms
▫ First “APIs”

Almost everything in big fat “solutions”
▫ Business logic
▫ Presentation
▫ Persistence
▫ i18n
▫ ...

Industrial revolution (2011 - 2013)
(Massive and continuous production)

Jumping into the micro-services wagon
(before the term even existed - we called it
then “SOA” without the fluff)

◦ Break pieces into REST services
◦ Build robust and modern client front-ends
◦ Ruby + Rails come into play

We started building a Rails app as the web
front-end with:
◦ Modern web practices
◦ Horizontal scalability
◦ Automated & smooth deployment
◦ Extensive test suite
◦ i18n built-in

Ruby + i18n
ルビー
‫ﯾﺎﻗوت‬
मा णक
рубин
紅寶石
માણેક

Building a globalized, customer facing e-commerce product, powered by micro-services (#21 Athens Ruby Meetup)

i18n built-in: whack a mole
◦ rudimentary support from rails for full
blown gettext (plurals, interpolations, keys
extraction, po backend)

◦ again, rudimentary support time formats
(15 Ιανουάριος)

◦ again, rudimentary support time formats
(15 Ιανουάριος)
◦ fallbacks working only as proof of concept
(:de_DE -> :de -> :en)

i18n built-in: number_to_currency
◦ Is slooooooooow
◦ Makes bad assumptions
▫ currency is determined based on locale
▫ reaaaally?

[1] pry(main)> i = 100.10
=> 100.1
[2] pry(main)> Benchmark.bmbm do |x|
[2] pry(main)* x.report('printf') { 1000.times { '%.2f' % i } }
[2] pry(main)* x.report('number_to_currency') { 1000.times { helper.number_to_currency(i) }
}
[2] pry(main)* end
Rehearsal ------------------------------------------------------
printf 0.000000 0.000000 0.000000 ( 0.004235)
number_to_currency 1.370000 0.070000 1.440000 ( 1.492025)
--------------------------------------------- total: 1.440000sec
user system total real
printf 0.000000 0.000000 0.000000 ( 0.001912)
number_to_currency 0.150000 0.000000 0.150000 ( 0.149475)

i18n built-in: performance/memory issues
◦ 4s to read the po files in memory (!) for
“just” 8 languages

◦ Solution: “compile” them to ruby code (!)

◦ Solution: “compile” them to ruby code (!)
▫ < 1s to load on startup
▫ but bloating the memory (> 40mb /
process)

i18n built-in: mighty “language selector” file
◦ 1.151 lines of case-d ruby code

javascript
◦ autocomplete
◦ latinize
◦ upcase
◦ strip “invalid” characters

UI/UX
◦ different languages → different space
requirements on the screen
◦ different font requirements (e.g. arabic,
thai)
◦ different font size requirements
◦ RTL (lol good luck)

Translations management
◦ still <3 transifex
◦ still <3 Gettext parser

Translations management
◦ still <3 transifex
◦ still <3 Gettext parser
◦ (new) homebrewed bunch of scripts
syncing with transifex and
committing to repo

But, translations are managed by
humans...

But, translations are managed by
humans...
◦ missing translations
◦ translated interpolation keys
◦ broken interpolation keys
◦ missing interpolation keys
◦ imaginary interpolation keys
◦ hard-coded values

1st take of automated QA for
translations:
→ smoke tests
◦ … a lot of them …
◦ … 3 hours to run …
◦ but saved a lot of releases

Apart from the main Rails Web app, we
started building another big Rails app as the
CRM back-end

And a whole zoo of standalone services
serving content & business logic in the middle

During this time the second (bigger) wave
of new markets came along

Launching a new market was still a major
project
~ definitely less than a year
~ much more streamlined
~ 2 new markets per year
but still a big and dodgy project

◦ Logic was still hard-coded
◦ Macro complexity has increased even
though micro complexity had decreased
◦ Sync different teams, with different
codebases, different apps, even different
technologies

TODAY
(2015 - and still no hoverboards)

Today
Went from to 12 “markets” to...

54 Countries
(Actively managed, most with local phone
numbers, etc)
33 Currencies
(All payable)
38 Languages
(With at least 90% completeness)

~ 1,800,000 users
(per month)
with 400 locales
(“el-GR”, “ru”, “en-US”, etc)
from 234 countries
(Including names like “Djibouti”, “Belize”, etc)

7+ different “platforms”
(Web, iOS, Android, SMS, emails, telephone,
push notifications, more to come?)
40+ releases / week
(0 downtime… mostly)
Tens of services
(running on C# and Ruby)

Time To Go Live
◦ Company level time to go live: ~ 4 weeks
▫ translations
▫ configurations
▫ release
◦ Dev level time to go live: couple of days

Our approach
One codebase (per app) supporting
different configurations
vs
multiple different deployments

Our approach
Make these configurations dynamic (at
runtime) and not statically configured (in
files or code)

Our approach
Introduce a new (configuration) service

Our approach
◦ Share configurations to multiple services

Our approach
◦ Separate deploy schedules

Our approach
◦ Centralized configuration logic

Our approach
◦ Centralized configuration logic
◦ RIP mighty “language selector” xD

Configuration service
◦ Built with ruby
◦ Nginx + AWS S3
◦ Keep It Simple, Stupid™
▫ Read json files
▫ Process
▫ Permutate
▫ Output json configuration(s)
▫ Upload to Amazon S3 bucket (easy
deployment + free .9999 reliability)

Configuration service clients
◦ Query the service for settings using any
brand/country/language combination

◦ Clients do not care and do not make
assumptions (when you assume you make an ass out of u and me)

◦ Get all available info for the combination
they asked for

◦ Get all available info for the combination
they asked for
◦ Can get extra info on demand (e.g.
validation rules, legacy market mappings)

Configuration service challenges
◦ Micro-services → update tenths of
applications to read from configuration
service (code + tests + deploy)

◦ Legacy systems

◦ Legacy systems
◦ Caching / performance / availability

◦ Legacy systems
◦ Caching / performance / availability
◦ Some of your data becomes irrelevant →
migration tasks

Currencies!
UX (and not only) sophistication for
currencies
◦ symbols
◦ delimiters
◦ precisions (!!!!!)
◦ roundings (!!!!!!!!!!!)

Streamlined translation process
special screen with upcoming
translations
+ per git branch
＝ better co-op with translation teams

Turbo-charged automated QA for translations
2nd take of automated QA for
translations:
→ translations checker:
▫ homebrewed build scripts that check for
■ errors (missing/wrong interpolations)
■ warnings (duplicate
keys/lines/interpolations etc)
▫ run in CI after each commit
▫ run in seconds
▫ have paid off again and again and again

Turbo-charged automated QA for translations

So… we are ready
to Go Global™
Right?

“
Simferopol is a city on the Crimean
peninsula, the status of which is
disputed between Ukraine and
Russia. It is the administrative
centre of the Autonomous Republic
of Crimea or of the Republic of
Crimea.
(from Wikipedia)

Simferopol
Is in Ukraine for Ukrainians
Is “autonomous” for a lot of others
Is in Russia for Russians

“
Kosovo is a partially recognised
state in Southeastern Europe that
declared its independence from
Serbia in February 2008 as the
Republic of Kosovo.
(from Wikipedia)

Localized business logic
What’s the best sorting in
autocomplete suggestions for
query “PAR” between Paris, Paros &
Parma for:
- Someone from Greece?
- Someone from Italy?
- Someone from France?

Biggest mistakes
Treating all localization content as
plain “translations” (and
delegating to client apps)

Biggest mistakes
Packing translations with
configurations (telephone numbers,
addresses, etc)

Biggest mistakes
Hard assumptions (if currency is
“RUB” then it must be “trip.ru” in
“Russian”)

Biggest mistakes
Treating localization projects as
“translations” projects

Biggest mistakes
Treating localization projects as
“once off” tasks

What’s next?
The RTL time has come (WIP)

What’s next?
Configuration service has worked
astonishing well but there is room
for improvements

Configuration v2.0
◦ Move more environment
configurations to the service

Configuration v2.0
◦ Client subscriber functionality

Configuration v2.0
◦ Partial data updates

Configuration v2.0
◦ Partial data updates
◦ UI

Configuration v2.0
◦ Build upon what we currently have
◦ Evaluate other solutions
▫ Apache Zookeeper
▫ etcd
▫ consul
▫ ???

CLDR
Kick out 99% of ruby i18n gem and
replace it with ruby-cldr
(maintained? from twitter)

Thank you <3
(that’s not me btw)

Building a globalized, customer facing e-commerce product, powered by micro-services (#21 Athens Ruby Meetup)

More Related Content

Similar to Building a globalized, customer facing e-commerce product, powered by micro-services (#21 Athens Ruby Meetup) (20)

More from Nikos Dimitrakopoulos (8)

Recently uploaded (20)

Building a globalized, customer facing e-commerce product, powered by micro-services (#21 Athens Ruby Meetup)