I am going to build raspberry pi based device which reads data from sensor bus (serial port), analyzes it and present it on touch screen. Touch screen will be also used for configuration. Device needs to have web interface with equal functionality. What I am planing to do is to split application for 2 or 3 separate (python) applications with database as medium for exchanging data. Flask based for web interface and kivy based for touch screen. In order not to choose which one will be master that reads sensor bus I am thinking about introducing third one (headless) that is doing main job - getting data, analysing, producing events and storing them into database (MongoDB or MySQL). Theoretically all frameworks could work in one program in separate threads with common data space, but it seems to be less elastic, and more difficult to maintain and adding another interfaces (e.g. another serial bus to talk to other devices) not mentioning integration with nginx. Is that right approach? 
Architecture of app with two independedt interfaces (web, touch screen)
architecture;python
You approach is fine is this case, divide and conquer in my opinion is the best approach when dealing with different inputs and output.i would design it like this: One app to act as an API and the brains for the other apps that only collect input.i would leave the responsibility of displaying information on a web page or/and touch screen with the API app (flask app).  Have the touch screen code at the flask app. and after you done, see if its a good idea separating it. since it will be running under a different thread, the code will be written in a way, that will allow reasonably easy separation later.the only problem i see is, the Database as a means of communication.   all your applications will depend on the database to communicate, it will put a load on the DB, that you will have to take into account.also DB locking need to be taken into account, since you may write to the same place from different sources. database will become as a single point of failure - DB down or broken ==> no app.its also harder to scale or distribute you app with a DB dependency.it will persist data that don't need persistence like serial input.after a while your DB will be huge unless you clean itusing a DB as a means to communicate between apps is usually not a good idea. for persistent data of your flask API app you can keep a database, but not for communication.i see two options for communication between your services/appsjust have the agent (serial input) to invoke endpoints at your RESTful API. and in turn it will do its magic, and display the info on web and touch screenmessage/queue maybe using redis or rabbitmq. like lonstar suggested. but its more complex and maybe overkill for your needs