Capacity planning (or sizing) of an environment is the process of determining the number and configurations of various components in an environment, so that the system requirements and business goals are satisfied with the required SLAs. This is not an exact science but rather its rough calculations with input from required SLAs, past design experience, domain knowledge, and applied creative thinking.

For computes, the main resources are CPUs and memory. The domain knowledge and system design indicate how much of these resources are needed for a single request:

• Is the API handling resource intensive? If yes, then more core CPUs might be needed.
• Is the API handling IO bound? If yes, then ancillary hardware like DMA will probably impact performance (rather than larger cores).
• If there is a lot of in-memory caching or recursion, then memory requirements might be large.

With these inputs one can characterize how much a single instance (of specified specifications) can serve in terms of requests per second. Once we know that each instance can handle x requests/sec and the SLA required from the service is y requests/sec, then the total number of instances can be easily found out using ceil(y/x).

As described in Chapter 8, Modeling Data, databases come in various forms and shapes. However, there are a few general considerations for production deployment:

• High availability: Ensure that no DB instance is a single point of failure.
• Storage configuration: The DB writes data to the disk. In most modern operating systems, this path is not as straightforward, and care needs to be taken to ensure that durability and performance goals are met. This includes various buffer/cache parameters in the filesystems.
• Backup: Most business-critical data is also backed up. This involves periodic snapshotting and shipping of this snapshot to a remote archive.
• CPU/memory requirements: Depending on the number of IO operations to be supported per second, appropriate CPU and memory needs to be provisioned for the the database instance.
• Compliance and access control: Production data needs to be appropriately secured such that only only a limited required set of users have read/write access to the databases. Some data might be needed to be kept encrypted (privacy concerns).
• Scripting of creation/modification of the database entities (tables, views, procedures, and so on) and having the scripts in source control.

Golang is much more resource efficient than other languages like Java. Thus, even if you have an existing system that you are migrating, the preceding exercise is fruitful.