Gilt Tech Blog

Gilt Groupe - NYC (full-time) http://www.gilt.com (web) http://m.gilt.com (mobile) We're currently looking for: * Front End Engineer * Generalist Engineer * eCommerce Product Manager * Senior UX Designer * Machine Learning & Recommendations Engineers * LOTS MORE: http://www.gilt.com/company/careers/jobs Check out our tech blog here: http://tech.gilt.com

NYC. Dublin. Limerick. VISA. Gilt - www.Gilt.com We have small, autonomous teams. Decentralized decision-making. Scala. NoSQL. Team ownership of end-to-end quality. Support for open source technologies. A friction-free production environment. Distributed systems. Continuous delivery. Simplicity. Automation. ============================================================== More than 50 percent of Gilt’s traffic–and more than 40 percent of our revenue–comes from mobile devices, and we expect these numbers to increase over time. Given this projected growth, the Gilt Mobile team continuously works to discover new and better ways to build the lightest, fastest mobile experiences possible. That means developing custom applications that can successfully release millions of push notifications within seconds, devising ways to automate testing to match people’s behaviors, and creating the most elegant user experiences in the industry. The dynamic nature of our operations means that there’s always something new to learn, develop and explore. Think an iOS role is for you? Apply here: http://www.gilt.com/careers/job/r1602/ ============================================================== We are looking for Product Managers, Systems Engineers, Leads, Front-End Architects, Business Intelligence Engineers, Network Engineers, Big Data Scientists and more. Check out our openings here: http://www.gilt.com/careers/department/technology-product-management/ Feel free to apply through our…

Here's an example of the kind of speedup you can see from proper usage of NSOperationQueues: http://tech.gilt.com/post/3187131303/tips-for-optimizing-iphone-ipad-a… Pretty impressive to see them running side by side.

Okay then. Let's play the "hard nosed technical justification" for this new architectural mold. Specifically pointed at your issues. > The serialization/deserialization layer adds potential for bugs. Adding an agreed upon layer that aligns with clean architecture[0) will actually produce less bugs both upstream and downstream. (This is why contract apis are important) and are actually more valuable than monolithic systems where there is a sincere lack of data and state guarantees. (clean understanding vs black box mentality) > The massively increased number of services all need constant monitoring. It's the same amount of monitoring. It's just horizontally scaled and is actually easier to pinpoint issues. This also allows you the ability to change or create circuit breakers to fail over when issues targeting specific are found. (see slides 134-150 of Sam Newman's principles of microservices [1]) > The massively multiplied error conditions (what happens when service 37 talks to 39 and 39 times out?) need to be accounted for and those edge cases must be ironed out. They should have been "ironed out" well before this point to begin with. If the application fails due to infrastructure issues, it is actually an application design failure that should have been identified and resolved previously via TDD and failure state testing. Graceful failure is always desirable, and having a legacy monolithic application does not prevent infrastructure/connectivity failures. (for…

Elixir is usually the best bet for high throughput with low memory requirements. But I think you should read some presentations about microservices before you decide to code a giant new architecture. There are other solutions already developed. A guide on the mindset of microservices that is useful is well written in these two articles: http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/feat… and http://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that… Xing used elixir/erlang built an rabbit mq, riak, and redis based service that seemed like a good build for scaling a large system with minimal memory and latency. You can watch that video here: https://www.youtube.com/watch?v=38yKu5HR-tM For scaling microservices you generally want to use http and queueing services for distributing the messages. There are many options in this retrospect. Redis and RabbitMQ are some of the better ones. Something newly being developed but could be of interest is syncfree: https://github.com/SyncFree . The reason syncfree is a good fit for a distirbuted service is it will not get bulky from updates based on timed services. For the rabbitmq version of riak: https://github.com/jbrisbin/riak-exchange An alternatives to riak is hibaridb, but may take a bit more work to get functional with other stuff: https://github.com/hibari/ With http APIs you can just curl into your APIs. Or load balance and proxy…