How to Implement an ESB Layer Correctly on the First Attempt

Last year, KT.Team implemented a service bus for the ATIMO startup, which built an app for automatically obtaining route sheets for drivers. ATIMO works with taxi fleets and vehicle fleets that do not want to keep a mechanic and a medic on staff.

These companies use automated checkpoints for vehicle inspections and driver health checks. At these checkpoints, a technician and a doctor perform inspections and upload the results to the ATIMO system for processing.

The taxi fleet sends driver and vehicle information to ATIMO and receives a completed trip sheet in the app in return.

While there were only two taxi fleets, each was connected directly to the system, but future scaling made ATIMO reconsider the architecture of its IT solution.

At this stage, ATIMO reached out to KT.Team.

They needed a service bus, software that flexibly integrates different systems.

The bus was meant to handle data exchange between the taxi fleet, technical and medical inspection points, and the ATIMO databases without overloading the server.

At the start of implementation, only two taxi fleets needed to be connected to the bus, so the KT.Team team chose a fairly simple approach. ESB 1.0 ran for six months, during which new taxi fleets began being connected to the ATIMO system.

When their number grew to 10, it became clear that the bus was completely not fault tolerant.

The problems were caused by an initially incorrect bus architecture: the more databases connected to it, the higher the risk of failure.

The databases were queried sequentially, and if one did not respond or dropped the connection, the bus stopped working. In other words, if a failure occurred when connecting to the very first taxi fleet, all the other taxi fleets were also left without waybills.

In addition, a message broker was used to transfer information into ESB 1.0.

The bus forwarded data between the taxi fleet and the ATIMO system as is, without processing it in any way.

The exchange was not always correct, and part of the message could be lost.

Using separate services for each connection will make the architecture less coupled: a failure in one database will not affect data exchange with the others.

This architecture will be more fault tolerant.

To make data transfer more stable, it is better to use internal storage, the bus's own databases.

The bus will receive data from the taxi fleets' databases and from ATIMO, then store it internally.

That way, data transfer will work faster and more reliably.

The KT.Team planned to use several data collection services in ESB 2.0 instead of one and two internal databases instead of a message broker. In the end, they implemented an intermediate solution: they kept one service for all taxi fleets, but completely changed the data exchange logic.

The message broker was replaced with databases: one for vehicle and driver information, and another for completed trip sheets. The bus then pulled data on demand from these databases into the ATIMO system or to the taxi fleet.

This decision was made for two reasons. First, the new bus version required more resources, since all taxi fleets had to be processed at the same time rather than one by one. Second, the customer prioritized rapid implementation of changes, while a full architecture redesign would have taken some time.

ATIMO also asked for more frequent polling of the taxi fleets, with new data loaded every minute.

The project team also met this requirement: technically, the bus can run even faster. However, the taxi fleets' databases could no longer handle that speed.

For one especially slow database, we had to artificially limit the number of requests, because it treated minute-by-minute connections as a DDoS attack and blocked the bus.

The update was implemented, and ATIMO immediately noticed the improvement.

The bus operated without failures, and there were practically no support requests.

The solution turned out to be memory-efficient and stable enough.

At first glance, everything looked great: ESB 2.0 ran stably, and new taxi fleets were successfully connected to it. After about a month, there were already

The problem was that the ESB architecture remained incorrect: one service sequentially queried all 15 databases.

At the same time, the ATIMO system kept growing, and it was clear that sooner or later the bus would start failing again.

The mistake in this version was that the project team focused on saving server resources and reducing development time.

The key architectural problem of ESB 1.0 remained in ESB 2.0, so the bus had to be refined again.

For an ESB to be truly fault tolerant, it needs the right architecture.

The best approach in this situation is to discuss realistic development timelines with the client.

A full redesign takes time, but it also delivers a scalable and reliable data bus.

The KT.Team team already knew what needed to be changed, so it did not wait for a request from ATIMO or for an ESB failure and redesigned the bus on its own initiative.

In ESB 3.0, we implemented the architecture we had abandoned in the previous version, with separate services for each database.

All services work the same way: they connect to the taxi fleet database, download data from it, convert it to the format used by the ATIMO system (mapping rules were set up for this), write new data to the store, and remove outdated data.

Use the right architecture: one service for each connection.

Such a bus is resilient to failures in individual databases.

To keep the services from consuming too many server resources, they were made as simple as possible: all unnecessary and resource-intensive steps, such as exception logging, were removed.

Instead, the data in the store is overwritten on every successful connection to the taxi fleet's database.

Polling one taxi fleet now requires about 300 MB of memory, instead of 4 GB at the start of the project.

The final version of the service bus was rolled out shortly before 2023 began.

After that, KT.Team did not receive a single technical support request until the end of January. And ATIMO's first question was not about the reliability of the service bus at all.

The thing is, ESB 3.0 has a useful feature: a new connection point for a taxi fleet can be created by simply cloning any existing one.

Then you need to set a few parameters, and the ESB will be able to retrieve the required data.

This solution made the bus scalable, so ATIMO does not need to contact support to add a taxi fleet.

The KT.Team team created a step-by-step guide to make the process clearer.

The first question from ATIMO was about that step, because the description of one of the steps was not entirely clear.

We answered the question, adjusted the text, and now adding a new taxi fleet takes only a couple of hours instead of several days as before.

"ATIMO" successfully integrates new taxi fleets with ESB 3.0 without KT.Team's help.

In the first 3.5 months of 2023, the startup team added 10 new integrations on their own using the documentation.

There are already 20 taxi fleets in the system, and the number of databases from which the bus pulls driver and vehicle information is twice as high.

ATIMO's limited server resources are used sparingly: one request uses only 300 MB of memory instead of 4 GB with a direct connection.

Consumption was reduced thanks to a very simple service design that queries the taxi fleet database. The support chat is quiet: the bus performs its functions, and the occasional questions are related to minor local issues on the side of individual databases.

Most often, the issue resolves itself: the taxi fleet fixes its side of the process, and the ATIMO system receives updated data. In this case, the KT.Team team gained valuable experience and refined the ESB implementation process.

It is important to account for future growth and possible points of failure in the system from the start by implementing it properly.

So the best approach is to implement such a bus through separate services for each connection, even if there are only two for now.