Typical scapegoats for insufficient performance are relational databases. Usually, application servers are deployed in multiple instances that all connect against a single database instance. This is a necessity to ensure consistency due to the CAP theorem.
The database as a single point of responsibility, or failure, is predestined to become a bottleneck. Still, engineers must consider proper measurements to verify this assumption.
If metrics indicate that the database response is slower than acceptable, again the first approach is to investigate the root cause. If the database query is responsible for causing the slow response, engineers are advised to take a look at the performed queries. Is a lot of data being loaded? If yes, is all this data necessary or will it be filtered and reduced by the application later on? In some cases, the database queries load more data than required.
This is also a question relevant to the business, especially for retrieving data, whether everything is required. More specific database queries that pre-filter results or size limits, such as pagination, can help in these cases.
Databases perform exceptionally well when joining and filtering data. Performing more complex queries directly in the database instance usually outperforms loading all required data into the application's memory and executing the query there. It's possible to define complex, nested SQL queries in Java and to execute them in the database. However, what enterprise applications should avoid is to define business logic queries directly in the database, using stored procedures. Business-related logic should reside in the application.
A typical configuration mistake is also neglecting to index relevant database columns that are used in queries. There were many cases in projects where the overall performance could be improved by several factors just by defining proper indexes.
In general, the insight measurements of specific use cases usually provide good insights on where the issue might originate from.
In some scenarios, queries that update data often result in optimistic locking errors. This originates from domain entities simultaneously being updated. Optimistic locking is rather a business issue than a technical one. The service error rate will indicate such issues.
If the business use case requires that entities are often changed simultaneously, development teams can consider changing the functionality to an event-based model. Similarly, as shown previously, event sourcing and event-driven architectures get rid of this situation by introducing eventual consistency.
If the performance issues purely originates from workload and concurrent accesses, then ultimately a different data model is required, such as event-driven architectures realized with CQRS. However, usually the situation is solvable in another way. The vast majority of enterprise applications scale well enough using relational databases.