2015.01.13 E-Commerce Architecture Review
Presenter: Will Daly
Document: https://docs.google.com/a/edx.org/document/d/1qBeZG8Z-qqeHdTzQlS5e2-s6iuui7OEnzGZLzFp45W4
Attendees: Ned, Will, Steve Sanchez, Miki, Beth, Piotr, Dave O., Jason Bau, Steve Magoun, Nimisha, Cale, Ed
Will walks us through slides.
Goals next quarter:
Enable e-commerce features that we could build ourselves but would be one-off work, so we want to be able to get them elsewhere
flexible product catalog
product bundles
Independent deployment of e-commerce
a/b tests done quickly, optimize the pipeline
(miki) could also reduce the time to run tests
An open-source shopping cart implementation, more features than we have now
backend APIs for products, orders, discounts, etc.
more payment processors
provides an admin UI
NOT using the off-the-shelf user UI
whitelabel will need it
assuming the worst, and will need to a/b test the cart experience itself.
looking at existing open-source cart implementations
want to be good open-source citizens, will contribute back
Services
E-commerce front-end
UI for payment and verification
eventually, UI for course discovery and student dashboard
communicates with cart and LMS through well-defined APIs
need to support whitelabel, and open-source theming.
(cale) wasn't part of the point to avoid the complexity of whitelabel and theming?
(will) maybe we'll start with separation, and then add back in theming, but where we can, build in the hooks as we go.
for Q3, our focus will be on the velocity of the destedx team.
(steve m) can't compromise the cart in white label, it needs to work all the time
(will) end of q3, edx.org can switch over, then we can talk about whitelabel.
(steve m) could be tricky to support two carts, with untested assumptions between them.
(steve s) need good test automation for microsites to ensure no breakage.
(Beth) why are we not looking at whole e-commerce suites?
(Chris D joins)
(Miki) likes a homogenous tech stack, and wants to be able to support the open source community.
[Q3 Architecture drawing]
Payment processors: external now, but not necessarily
Report and Audit: Chris D has started it.
Looking to move course modes to be variants of products in the shopping cart.
"Product" vs "Course": carts will call it "product", and we need to be able to sell things other than products
in the diagram, e-commerce front-end and shopping cart are shown as two services, but we could combine them in one-process
(ed) will credit-card numbers ever be on our network?
for pci-compliance, we want them not to be.
[Post-Q3 Vision]
better encapsulation
drupal has a reduced role
more, smaller services
should we make it a requirement that services can run in-process for ease of debugging, etc?
defining a flexible in/out process layer will be a good strategy for pulling code out of the LMS
(steve m) resiliency in the face of service failure?
(cale) we have patterns for this, but we haven't implemented them.
(miki) is this different than the db being down?
(ed) yes, because db is essential, nothing can happen if it's down. These services, we could make more optional.
(miki) IDA addresses a lot of these sort of patterns. we need to do that.
(nimisha) feature-flag thinking already gets us thinking about optional services.
(piotr) latency? many network hops will mean a slow UI
(miki) we'll need to solve the response time problem.
Providers in other languages:
The bar is really high to choose a provider in a language other than Python.
If we choose one, we have to have really good reasons.
Comments needing response
What patterns will be used to make the system resilient to service failures?
All APIs should come through the Architecture Council
What approach is being used to be certain of interoperability with external services?
Payment processors can be re-chosen by other operators, but not other services.