Mall.cz

The problem

The marketing department of mall.cz needed a tool that would allow them to quickly and according to current needs make changes to the website menu, for example for seasonal products, various events, etc. At the same time, it was necessary to ensure that the history of changes was saved and that it was possible to return to individual changes if necessary.

Challenge

The main challenge was how to store the data so that a history of menu changes could be easily maintained: what edits were made by whom and when. Then also the promotion of the changes as such to the customer on the web.

Solutions

We used event stream and snapshotting to save the data. In this case, the data is not saved as a whole, only the operations that are performed on the data are saved. By applying these events to the default state, we get to the resulting data.

The basic operations are creating/editing and deleting an item. The default state is an empty menu.

The important factor is how the operations come in sequence. One must always proceed from oldest to newest when applying operations.

Thanks to this system, we are able to compile an overview of how the data looked at each point in time. When we add user information to each record, we then have a straightforward history dump because we clearly know what operations were performed, at what time, and by whom.

But the problem arises when we need to apply many events at once. It is not good to always start from the initial state, because the application of all events will gradually increase in time. Snapshotting reduces this problem. This is the continuous saving of the resulting state of data at a specific time. If we have a state stored at a time, then we get to the next state by applying events from that time onwards. Suppose we store snapshots with every 100th event. We are then assured that we always get from the previous state to the current state after applying at most 100 events, and we are able to allow a constant time to build the current state of the data.

The problem

One of the crisis areas of any web application is the speed of loading images. The goal of developers is to make sure that the user doesn't actually notice that any images are loading. If they do notice, it's not a good sign, and no one would be surprised if a user in such a situation quit the store for that reason.

Solutions

We opted for an AWS serverless solution because of the highly variable scaling of the service. We are thus able to scale the entire solution in a very short time and optimize millions of images.

The whole service works completely independent of any other service. Therefore, in order to be able to quickly scale the flow through a given service, we have prepared a REST API that works only to receive optimization requests. Its goal is to pass the optimization request to the queue and at the same time pass information to the requester about where to find the resulting image.

Then the actual optimization of the images takes place. We work with two variants. First, a very aggressive compression is performed, which can optimize the image to the marrow but still visually unchanged. However, in many cases (approximately under 1 percent of all images) the image fails to optimize. For these cases, we use a fallback option that can optimize (though not as well) virtually every image.

process

During the process, we had to deal with high resolution input images, but with one setting for the final optimization. In one of the solutions, we also counted on running multiple optimizations and then comparing them with the original image - i.e. to select the type of optimization that does not visually distort the resulting image in a machine-like way. However, after several measurement tests, it turned out that one method wins in most cases.

The problem

E-commerce customers may not realise that large e-shops are almost permanently improved by large teams of developers to make the shopping experience more and more user-friendly and simple. Attention should also be paid to such details as error reporting, which can discourage customers from making further purchases. If an error appears on the site, it should be reported as soon as possible so that it can be corrected quickly. We have been working on an app for MALL that can call up an error reporting form anywhere on the site. This form, once submitted, goes into the JIRA system and a request is filed here with all the details and information so that the error is specified as best as possible and can therefore be resolved as quickly as possible.