March 25, 2016

Event Sourcing at willhaben

This is the start of a series of blog posts about the introduction of Event Sourcing and Command Query Responsibility Segregation (CQRS) in one of our internal products. The first blog post gives a short introduction to these topics and talks about the problem domain and the current status of development. Further posts will talk about the concepts in detail and our lessons learned. So stay tuned for more.

The problem domain

At willhaben we currently deal with around 120.000 new ads and around 200.000 ad changes per day. For this data we need to make sure that the data adheres to our quality standards and to our terms & conditions, e.g. the ad must be placed in the right category. Also we want our users to be fair to others and not reinsert an ad in order to be pushed to the top of the search result.

For this reason we've developed a system where the people in the quality assurance department can define rules which implement the current quality requirements. The rules can be created, changed and deleted at runtime, making the system very flexible for rule editors because no developers or deployments are needed for changing business rules.

March 22, 2016

Implementing Leader Election and automatic fail over

Leader election and automatic fail over are two common tasks in every distributed environment. There are various reasons why multiple instances of the same software are running at the same time, for example because of load balancing, hot standby or dedicated instances for different tasks (same software but other configuration, etc.). Depending on your architecture, different aspects of these are more important than others. Furthermore, it is easier to develop services that have one master and one or more slaves than developing service set-ups in which every service is equal.

One common task would be having multiple services running for load balancing but only one that executes batch jobs like data base clean up jobs. This can be done in different ways, but one smart way would be to have the same configuration for all service instances and let the services decide at runtime which one executes the batch job (typically the master slave: the master executes the batch jobs and the slaves do not execute any batch jobs at all).

March 21, 2016

A taste of reactive components

The easiest way I can imagine to build a web application is just putting together some HTML and Javascript until I get more or less what I want. But usually, as the project grows, I end up with some unmaintainable mess. Why is that? Lets take a look at some code: