Is it a standard practice to have a single application/controller writing to database

Question

I've been interviewed by some experienced engineer, when he strongly disagreed with some statements I said:

• Assuming full control over your applications, It's a standard practice to make writes-to-database exclusive to one single application or controller (not about multiple application instances, but different applications).

• Assuming full control over design, synchronization is better implemented using observer pattern than using polling from both ends.

I'd really like for some experienced engineers to enlighten me on those 2 main points, and point to me if I've been right/wrong about them.

Answer 1

Is it a standard practice to have only one application writing in the database?

Not at all. A database is in general used to store, share and integrate information between many applications.

This is not to be confused with the very special situation of microservices, where often a database may be used exclusively by one service.

Is it a standard practice to make writes exclusive to a single controller

Not either. However, controllers have different roles in different architectural models, so it may depend. But if an application has different controllers (e.g. ECB model) , it's not rare either that each controller writes databases for its area of responsibility.

Note that in some systems the database accesses are isolated in a component or in a layer in charge of the persistence. But these components are rarely called 'controller".

Is synchronisation better implemented using the observer pattern ?

Define "better"! For some, better is more performant. For other it's more independence. For other it's the richness of information.

But nevertheless, yes, the observer pattern can have some advantages over polling in terms of performance:

• polling from both ends, mean that two systems constantly query the data from the other system to find out needs to synchronize. This can be costly, especially if one there can be longer iddle-times on one of the system, thus causing unnecessary queries. Polling also requires one system to know the data structures from the other system.
• observer pattern means that the writing system application informs its subscribers that something had happened. So data is queried only when it changes.

There are now a lot of systems that are build on an event oriented architecture. The events serve as a backbone and work according to the principle of the observer (the event queue is observed). This model can achieve high throughput in highly distributed systems.

Remark: the observer has nothing to do with versioning. The kind of "versioning" you are speaking in your comments is called event sourcing: this is a very special design for basing not only the synchronisation on events but also the persistence of objects. In this design you no longer save the state of an object, but the susccession of events that affect the state. This is realated to events, not really to the observer.