What technologies and architecture to choose when designing an access control server?

Question

Database

Good afternoon!
Now I am developing an access control server.
Tasks - providing the ability to connect ACS devices via the TCP protocol, storing the entire configuration of ACS devices in the database (cards, access rights), uploading all logs from the ACS to the database.
You will also need a convenient user interface to manage all this - adding / removing cards, editing access rights, viewing the history of events, generating reports and sending them out.
As a result, I decided to split the system into several fragments:
- TCP server, which provides communication with ACS devices via TCP.
- database.
- a management web server that provides the operation of such REST services as
* settings service,
* report service,
* mailing service
TCP server has all connected access control devices on one side, database on the other side.
I would not want to load it with some other work besides working with the access control system and the database.
All settings are loaded from the database, i.e. the server periodically checks the database for new events. In this case, the events are placed in the database according to the type of queue, i.e. sequentially and are also performed in the same way.
By this I want to provide simultaneous logging of all control commands.
Also, the unloading of data from the ACS devices goes through the database, i.e. The TCP server uploads everything to the database, where the history of all events is stored permanently.
Commands go to the database from the side of the web server from the user, and in the opposite direction, information is taken from the database by the user.
Criticize, please, my decisions.
Have I chosen the right path when choosing a database as an element of server communication?
While I see the bad points of this solution:
- if something happens to the database, then the TCP server control, loading / unloading data is impossible.
To avoid this, the idea was to use queuing services such as ActiveMQ / RabbitMQ as communication channels and, in parallel, duplicate the execution results in text logs and in the database.
- due to the fact that everything goes through the database, the database will introduce its own delays.
Perhaps I did not take into account some more points.

Answer 1

Give the database to the management web server and keep anyone away from it, performing all edits and selections only through the management server API. Life will immediately become easier, especially if the API is high-level, and not a duplication of CRUD.
And the server serving the hardware still needs to log everything that happens to it. At least in plain text - the logs will be needed only for disassembly with fakapami.