Choosing the right database for a microservice involves evaluating the specific needs of that service, such as scalability, consistency, and data complexity. Consider whether the data model is relational or non-relational, and if transactions are needed, as this influences the decision.
In depth
When selecting a database for a microservice, it's crucial to assess the requirements of that service independently. You should consider factors such as the expected load, read/write patterns, and consistency requirements. For instance, if the microservice requires complex queries and strong transactional support, a relational database like PostgreSQL might be appropriate. Conversely, if the service needs to scale horizontally and handle large volumes of unstructured data, a NoSQL database like MongoDB could be a better fit. This choice can affect the overall architecture, as different databases may require varying levels of management, scalability, and integration with other systems.
Additionally, it’s important to keep in mind potential future evolution of the service. What works today might not be suitable later, so ensuring flexibility and considering polyglot persistence—using different databases for different microservices—can be beneficial. This approach allows each microservice to be optimized for its unique needs, promoting better performance and scalability across the architecture.
Example scenario
In an e-commerce platform, the user service managed user profiles and authentication details, requiring strong consistency for transactions such as login. A relational database like PostgreSQL was chosen for this service, allowing for complex joins and robust transaction management. Meanwhile, the product catalog service, which needed to support high availability and rapid scalability, utilized a NoSQL database like DynamoDB, enabling flexible schemas and faster read access as product data grew.
Common mistakes
A common mistake is choosing a single database type for all microservices, leading to inefficiencies. Not every service has the same data requirements; forcing a relational model onto a service that handles rapidly changing data can result in performance bottlenecks. Another mistake is neglecting to consider the operational implications of a chosen database, such as monitoring, backup strategies, and the learning curve for the development team. These factors can greatly impact the long-term maintainability of the microservices architecture.
Follow-up questions
- What factors do you consider when deciding between a SQL and a NoSQL database?
- Can you explain what polyglot persistence means?
- How would you handle data consistency across multiple microservices?
- What are the potential pitfalls of using a single database for all services?
Preparing for a system design interview?
- A 7-step method for answering any system design question, plus estimation numbers
- 5 worked designs: URL shortener, rate limiter, chat, news feed and file storage
- Guides to caching, databases, queues, consistency and reliability, with a 4-week study plan
- 306 practice questions with answers on caching, databases, queues, microservices, APIs and more
5 worked designs, a 4-week plan and 306 practice questions with answers.
The material stays free to read online. This is the organised, offline, print-ready PDF edition. Secure payment by PayPal; your personal download link is emailed after payment is confirmed. Digital product, no shipping.