After watching a webinar on event-driven architecture, there was a slide on micro-services providing one responsibility and using one dedicated database. I’m not sure I specifically agree with the latter part of that statement. Not only does it push the mental cost of the architecture up and presents some performance bounds, but it also pushes up OPEX and maybe CAPEX if you’re on-premises.

On-Premises

If you’re running as a cost centre to support business applications, then maybe turning on a virtual-machine is fine for your use case. Each deployment style and the underlying hardware will provide a certain performance against some CAPEX and OPEX. Maybe you can do this, but I’m still not sure it’s required.

Even if you follow the serverless guidelines, then maybe a table on an existing database is fine, providing you have the performance head room and someone who knows what they’re doing with data modelling (because the key material between micro-services and islands of data must somehow relate).

Serverless

With serverless technologies like AWS DynamoDB (which is NoSQL), the whole “one database per function” argument looks more like one CRUD based access pattern, and all potentially on a single table, which despite sounding mad, is a great approach. This also presents the bonus of having a near ‘from zero upwards’ cost model, in which the cost of the database increases with the use of your service. It’s fantastic for testing ideas but also for cost modelling.

Regarding performance, you pay for what you use, and providing you keep an eye on how your data could be distributed and hashed between the underlying storage, you have the sky to go at.

Internet Scale

Going internet scale might not be a requirement. Therefore, simple technology used the right way will more than suffice. If you think you can grow to a multi-billion dollar organisation, then good for you! The access pattern per serverless function approach gives you an easy way to keep a track of key material across your application and if you follow the single table pattern, welcome to life on easy street. I find it magical that through one table, I can model a user’s journey through a system and test ways of adding functionality. In short, one database per microservices function is a bit far fetched in my opinion, but viewing it through the lens of one access pattern makes total sense. As always, it depends, but figured it was worth starting a raging debate!