Articles tagged with
architecture
12 Apr 2024
In early 2024, I hit ten years at Allegro, which also happens to be how long I’ve been working with microservices.
This timespan also roughly corresponds to how long the company as a whole has been using them, so I think it’s a good time to outline the story of project
Rubicon: a very ambitious gamble which completely changed how we work and what our software is like. The idea probably seemed rather extreme at the time, yet I
am certain that without this change, Allegro would not be where it is today, or perhaps would not be there at all.
05 Apr 2023
Hermes is a distributed publish-subscribe
message broker that we use at Allegro to facilitate asynchronous communication between our
microservices. As our usage of Hermes has grown over time, we faced a challenge in effectively distributing the
load it handles to optimize resource utilization. In this blog post, we will present the implementation of a dynamic
workload balancing algorithm that we developed to address this challenge. We will describe the approach we took, the
lessons we learned along the way, and the results we achieved.
13 Feb 2023
Software Architecture is an elusive thing which, if neglected, can lead to a hard-to-develop and maintain codebase, and
in more drastic circumstances to the failure of a product. This article discusses one of the backend application
architecture styles which proved to be successful in providing a good foundation for building and maintaining an
application in the long run: Onion Architecture.
13 Dec 2021
The Clean Architecture concept has been
around for some time and keeps surfacing in one place or another, yet it is not widely adopted. In this post I would
like to introduce this topic in a less conventional way: starting with customer’s needs and going through various
stages to present a solution that is clean enough to satisfy concepts from the aforementioned blog (or
the book with the same name).
09 Nov 2021
Every e-commerce platform needs some kind of central authorization system. At Allegro we use
OAuth and have our own implementation that stays true to the
RFC. Allegro has millions of users. There are also a lot of requests
that go through OAuth services. At some point there comes a need to have better control over how much traffic we want to
allow in a certain time window, while maintaining full performance of the platform. Here is where the idea of
rate-limiting comes in handy.
26 Oct 2021
This article describes a classic case of refactoring a search form UI component, a critical part of every e-commerce
platform. In it I’ll explain the precursor of change, analysis process, as well as aspects to pay attention to and
principles to apply while designing a new solution. If you are planning to conduct refactoring of a codebase or just
curious to learn more about frontend internals at Allegro, you might learn a thing or two from
this article. Sounds interesting? Hop on!
07 Dec 2020
Marketing is a very important department in every company. In case of Allegro,
marketing is especially difficult because you have so many products to promote.
In this post we will tell the story of a platform we built for marketing
purposes.
01 Oct 2020
Most applications need to be able to persist and retrieve their state to be fully functional.
In my previous post I compared methods for persisting application state.
In this post I will compare the methods for retrieving this state.
16 Jul 2020
We run over 800 microservices in our on-premise and public clouds. They are developed by hundreds of engineers
in various technologies: from the most popular Java and Kotlin, through Scala, Clojure, Python, NodeJS, Golang, to
less mainstream like Elixir or Swift. All these applications need to handle common
technical concerns: logging, monitoring, service discovery, tracing, internationalization, security and more.
How to provide common solutions to these requirements in such a heterogeneous setup?
In this post I’m going to explain how we originally solved this problem with common libraries
and how we are currently changing our runtime environment to make things even easier.
22 Jun 2020
An application can be defined as a set of use cases.
It often happens that use case A requires a previously executed use case B for its execution.
In such situation, it should be ensured that use case B has been executed while executing use case A.
To achieve this, application state that is common to both use cases, is introduced.
The state must be persisted to be visible to more than one use case.
Most often, various types of databases are used for this purpose.
While working with source code, I have encountered various methods of persisting the application state.
I also came up with my own variations.
In this post I will make a subjective comparison of these methods based on specific criteria.
07 May 2020
This year Allegro.pl turns 21. The company, while serving millions of Poles in their
online shopping, has taken part in many technological advances. Breaking the monolith,
utilising public cloud offerings, machine learning, you name it. Even though many technologies
we use might seem as just following the hype, their adoption is backed by solid reasoning.
Let me tell you the story of a project I’ve had the privilege of working on.
07 Jan 2020
When designing the architecture of a system, one always needs to think about what can go wrong and
what kind of failures can occur in the system. This kind of problem analysis is especially hard in distributed systems.
Failure is inevitable and the best we can do is to prepare for it.
12 Dec 2019
One of the first challenges a programmer has to face is organizing classes within a project.
This problem may look trivial but it’s not.
Still, it’s worth spending enough time to do it right.
I’ll show you why this aspect of software development is crucial by designing a sample project’s architecture.
21 Apr 2017
In our services ecosystem it’s usually the case that services can handle
a limited amount of requests per second.
We show how we introduced a new algorithm for our publish-subscribe queue system.
The road to production deployment highlights some key distributed systems’ takeaways we’d like to discuss.
12 Mar 2016
Microservices
are now the mainstream approach for scalable systems architecture.
There is little controversy when we are talking about designing backend services.
Well-behaved backend microservice should cover one
BoundedContext
and communicate over the REST API.
Things get complicated when we need to
use microservices as building blocks for a frontend solution.
How to build a consistent website or a mobile app
using tens or sometimes hundreds of microservices?
08 Jan 2016
Microservices architecture has been given a lot of attention in recent years.
You can find many articles defining what it is and explaining the difference
between microservices and monolithic applications. Unfortunately, the dark side
of the solution is rarely mentioned — such as its level of complexity and how difficult it is to
design it correctly.
Nevertheless, I would like to talk about my experience with microservices
architecture. I hope that this article will help you avoid the mistakes I made
and save time.
11 Feb 2015
Allegro was founded in 1999. As you can imagine, technology was quite different at that time.
Small startup of three developers wrote first version of the platform. There was no problem with scalability as there
were only hundreds of users. We didn’t even used any sql database. All data were stored in the files. This first few
years of Allegro are all almost mythical for current developers as no code or data schema is preserved from these
times. Over all those years we have grown up – a small company hiring a few programmers has changed into a
corporation with dozens of teams and hundreds of programmers. Everything was much easier back then when people were,
literally, working together. But with the growing number of programmers, we faced problems that soon turned into
blockers. Our code and its complexity grew along with the company. After some time, we realized that such uncontrolled
growth would block us one day. Application maintenance would become expensive, and any change of the system
behaviour would be risky. That is why we decided to act and our today’s architecture is the result of that decision.
Here is the story of our transition.
21 Jan 2015
Any programmer can admit that working with code that has been developed for years by many people is a difficult task.
Keeping your own application architecture clean is troublesome, and it gets even more challenging in case of an application
that was written by other programmers several years ago. One can enjoy writing new applications and tools that do
not carry any burden, but each product evolves together with its business assumptions. Moreover, new features are added
and the application needs to be constantly improved.
