When communicating tech issues to non-technical stakeholders, I focus on simplicity and relatability. I might use an analogy, like comparing the database to a crowded restaurant, where too many customers lead to delays in service. This helps them visualize the problem. Then, I explain how the slow performance impacts the business, such as causing delays in customer transactions or making it harder for employees to access crucial data, which ultimately affects productivity and customer satisfaction. Finally, I offer clear, actionable solutions, like optimizing queries or upgrading infrastructure, to show that steps are being taken to resolve the issue and prevent future disruptions.

Giving a visual example usually helps people to see the needs to upscale your DB, example: Imagine your database as a closet, initially your clothes, shoes and other stuff will fit in, but over time as you continue to buy (grow), the space won't be enough anymore. what if your family grows, having your cabinet already full, where are you placing the new member's stuff? Just throw inside and make a mess? You need to throw some stuff, which most of the time it isn't enough or even better add more physical space by getting a bigger closet or adding more shelves. Now substitute the idea of clothes, shoes and other stuff as business data, most business are data dependent, we need space to store those data to perform well in the market.

Imagine you have eaten more than usual and you can handle it but can you handle a new item on the menu? Simply put the process is jacked up which will cause unthinkable problems which will cause further financial problems. Inorder to complete and keep completing daily tasks and keep up with the trend an expansion is required. Going back to full belly, imagine you get an extension to your belly and you can diguest twice as much. How does that sound? Fantastic 99.9% of the competition are about to upscale. Are we going to wait or do we follow the principles of staying on top of things? Your answer will help me define further steps required to protect and maintain the CIA triad.

It helps to keep logs and metrics handy and use visual representation of how the scalability limits are impacting response time and / or throughput of existing system. Model a test environment that shows how a proposed solution addresses the scalability issues and do a side by side comparison of logs and metrics analysis. If the scalability limit is impacting SLA, show it in numbers and charts. That will easily be consumed by non-technical stakeholders.

Use a real-time example: Imagine to fill a large jar with peanuts using a funnel. Initially, the peanuts flow through easily, but as the demand increases (more users, data, or processes), the funnel becomes a bottleneck, slowing everything down. This is what happens when a database reaches its limits; it can't handle the increasing "traffic" efficiently, like: Vertical scaling: Increase power of server adding more CPU, RAM, or SSD capacity - e.g. buying a bigger funnel. Horizontal scaling: Also known as scale-out, this involves adding more nodes to share the load - e.g. have a funnel with 2 outputs