Designing Database Architecture

Designing Database Architecture

Many websites and web applications can be operated with a single-server configuration, where your database exists on the same server as all of the application’s other software components. This can be appropriate when your server (possibly when paired with external storage, like block storage) has enough compute and storage resources to accommodate your application’s data and traffic. This approach is fine for smaller, general use websites that might host some forms and media files. For example, a WordPress blog can run well on a single-server setup.

As your application’s features and data requirements grow, your database infrastructure needs additional flexibility and scalability to meet the performance expectations of your users or customers. Necessary changes could include moving the database to its own compute instance(s), or designing an advanced architecture with replicas, read-only instances, sharding, and/or other components These changes can enhance both the performance and security of your database.

Application performance is a shared responsibility Even if you or your team doesn’t currently prioritize conversion rates, poor application performance will come back to haunt you in other ways, including: decreased user trust, violation of your application’s SLA (the guaranteed availability of your services), and an increase in support tickets.

Research into human response indicates applications have roughly 100 milliseconds (ms)—one third of the time it takes to blink— before users feel like they’re waiting for a response

Lee Atchison
Caching at Scale with Redis

To help get you started, here are five examples of database-specific reference architecture that show how these setups differ, and their benefits. Please read more next post!