Question

Disclaimer: The author of this post has only theoretical and almost no practical knowledge about software architecture for web applications.

Let’s say I want to build a web app with the following architecture outline:

1. A typical web frontend, that lets users to create/edit/delete an account and creates/updates/deletes the account records in…
2. … the database, which stores all users’ accounts;
3. and a Jabber bot (a separate service, maybe on a separate physical machine) which speaks to the users, but needs to look up and update stuff about the users in the same database (2).

So, essentially I have two applications that use the same one database. I am not sure it is a good solution due to data integrity, race conditions and other issues.

I typical use case could be: User1 is interacting with the Jabber bot (3) and the bot needs to look up and update data in the database, and at exactly the same moment User2 creates an account through (1), which requires some interaction with the database (2).

How can avoid that type of architecture while keeping the required functionality? Or how can I design the architecture in a way that eliminates the need to query one database from two distinct services?

(unfortunately the ‘business model’ of this app does not allow having ‘account management'(1) and ‘Jabber bot'(2) logic in one web service).

P.S. The most important requirement of the system in question is high availability (maybe it would affect the answer somehow).

Answer 1

There is no problem with querying or updating the database from two distinct services. Databases are designed to serv several different requests concurrently and it is indifferent for the database whether these concurrent requests come from the same application or from different applications.

Even if we remove the Jabber service (3), you can still have several concurrent web-requests being processed by the web app (1) and that will create parallel database queries.

There is no problem with that, until you reach a certain limit.
Once you’ll grow above a certain limit (let’s say 1000 concurrent requests, but the actual number depends on different circumstances) you may have to cluster your database.

But before you reach that, you will face other bottlenecks for performance. E.g. setting up caching properly will let you serve more users with a single instance of the database server.