Tradeshift Engineering Intro Part 3— Stack, Architecture and Engineering Processes

This is part 3 of the Tradeshift Engineering Intro Series.

Developer Stack

We use a lot of technologies, with a few core languages whose first four letters are Java (Java and JavaScript) that represent about 90% of the work. We do like to experiment, so sometimes try new technologies, especially if they are in a low-risk areas. We also have some projects in Scala and Go. For example, one of our developers wrote a very simple SMTP daemon with a REST interface in Go, which we use for testing. We also have some support teams using scripting languages like ruby, python and php.

When you operate at certain scale, having deep understanding of your stack becomes crucial (and difficult). We limit the number of runtimes we support, mostly to the JVM and Node.js.

Drafts of this post features a list of technologies we use, with some light commentary. I decided instead to turn it into a mind map, I think it’s more interesting to view. Enjoy! The nodes that are emphasized in blue are the technologies we rely on the most.

I’d like to highlight some of the choices and why they make sense for us. There are two main parts of our stack — backend RESTful services, written mostly in Java, and the user-facing stack — single page apps written in Angular.js which have their own server-side component in node.js. The node.js layer interacts with the backend services. The latter allows our front-end developers to be fully in charge of user experience. When our users interact with the platform, they seamlessly navigate from one application to another.

On persistence side, we are heavy users of PostgreSQL (aggressively upgrading to the goodies in 9.5!), and use ElasticSearch whenever we need search. A big part of what we do is sending business documents, such as invoices, purchase orders, goods receipts (in UBL standard) around, we use Riak as our document store. Riak has worked great for us. We also have Redis and Cassandra in a few specific places.

Architecture, Process and Techniques

I also wanted to highlight some of the architecture and process we use. Here is a second mind map showing those:

There are several things we do to help us deliver software faster. As I mentioned on a previous post, we use service-oriented architecture to separate our stack into manageable parts. The services expose APIs that are consumed by our front end application, and many APIs are also available to third-party developers. I mentioned above that we write our UIs as a series of small applications, which makes it easier to work on in small teams and iterate quickly.

Our architecture and a lot of the things we do are architected to support third-party developer ecosystem, and we use the same tools internally. For example, for both our own purposes and to ensure UI consistency with third-party apps, we have a UI component toolkit, along with design guidelines to guide the development.

We have a good culture of automated testing, done on several levels — unit testing, integration and end to end testing. Like many shops, we are not quite at a point where we have a Test Pyramid, but trying to get there. If Testing = Checking + Exploring, automated tests are good at the checking, but we also have dedicated QA professionals for exploratory testing.

We have some interesting experiments with event-driven architectures for some newer services, and are doing a lot of work on making our platform work in multiple data centers, which is a challenging problem. Our tenant isolation model was built from the ground up to support that use case by keeping all companies on our network separate from each other.

In terms of process, we are an Agile shop, with most teams using scrum, but some operating more in a scrumban mode. We also have a strong code review process based on github’s pull requests, including making sure there is good unit test coverage.

We also have a lot of interesting things happening on the operations side, that will be a separate post.

In case you are wondering if we are hiring, yes we are.




An inside look into the world of software engineering across Tradeshift's 15 offices globally

Recommended from Medium

Reasons to Try Netlify, and Why It Might Not Be For You

Tutorial: Creating or Updating NGINX domains/subdomains and adding Let’s Encrypt

Landing page for Digital Ocean’s NGINX config builder

How we do Agile

Mocking domain names in a maintainable and scalable way

How mining log templates can be leveraged for early identification of network issues in…

Rollback for microservices with Ansible and Jenkins

10 Mistakes to avoid when preparing for coding interviews

Delivering Continuously — Automation Of Software Deployments and Rolling Deployments

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jean Barmash

Jean Barmash

Head of Engineering @, Intelligent Manufacturing Execution for Life Sciences, from COVID to Cancer.

More from Medium

Apache Flink in 5 minutes

Kafka DR Strategy Using MirrorMaker 2

The Platform Event Tracking Pipeline at GetYourGuide

How to implement smart recommendation online learning in oppo Smart Recommendation Sample Center…