What are the most effective architecture patterns for your application?

How can this be a question when the nature of application is not known? Leveraging proper reference architecture helps as a starter when the nature is known.

Nos projetos que tenho atuado vejo que este tipo de arquitetura sempre convive com outros tipos para desacoplar alguns servi?os e até mesmo integrar com servi?os que demorar pra responder usando técnica de long polling por exemplo.

In my experience there is no silver bullet to address the problem. It depends on the requirements and circumstances. An architecture should make the product/solution effective which makes the project successful. This means the architectural choice also should balance the project management quality triangle.

This is a common architecture used for most applications; it's the most simple and can be easily deployed with the help of generics on any technology. Generic services can provide common algorithms, such as database operations. It's not a bad architecture, but these days, there are better ways to do the job.

Usage of Microservices architecture is a double edged sword and should be used with caution. The decision should depend on the scale of the problem you are handling and the future prospects of your application. Just because everyone says, "Loose coupling makes life easy", one shouldn't opt it because interservice communication can get really messy if not properly handled. The example of Amazon Prime going back from Microservices to Monolith should remind us that over-engineering can be painful at a later stage. That said, if you are making use of other services in the org and in-turn a microservice architecture can open up your services for other apps in the org is a good example where it can be used (Apart from the scalability requirement)

Layered architecture isn't exclusive by itself; you can create a microservice with a layered, hexagonal, onion, or clean architecture. While you can use the layered approach for the application itself, you can use microservices as a solution, involving an N number of layered applications. Microservices are particularly good for containerization; you can have microservices that are not commonly requested in a pod (like configuration and user endpoints) and high-performance microservices on another one, with auto-scaling configurations. You can also have different microservices in different technologies, depending on the requirements of each one.

Apache Kafka popularized Event driven architecture like never before and is extensively used across all applications of scale. Of course all interactions of asynchronous nature can be efficiently implemented using event-driven architecture, one of the apt real life use-case involves data migration projects. Change Data Capture (CDC) can be effectively realized using event-driven architecture.

I love this one. Event-driven architecture gives you the power to react to an event to perform some work. It depends on message software like Kafka, M.A.T.S., or a service bus, but it can dramatically improve all the processes of your ecosystem, providing near real-time computing. It also prevents high workload by creating a string of events of the same type, giving applications time to auto-scale, or simply allowing them time to finish the job.

Hexagonal is another way of representation of the architecture. It is the ‘ports and adaptors’ representation which goes well with domain driven design where the domain layer stands at the centre. It is preventing you from lock-in and making it easier for the application to leverage different tech stack over time by just changing the adaptors and ports as the application evolve.

Just like layered architecture, hexagonal architecture is an application architecture and should not be compared with microservices or layered architecture. We can have, in the same solution, a layered microservice just like another hexagonal, and both or none can use event-driven. But talking about hexagonal itself, the pattern provides a core, with the use cases at the center, and any kind of interaction with them must be done using a port that leads to them. The ports are accessed by adapters, which connect to the external world. That's an amazing architecture to use when the team must focus on use cases, for testing, and flexibility.

More than from the technological perspective, it serves the business perspective by bringing in the capability to reduce Time-To-Market (TTM) effectively. The engineering team can focus on the code and the rest would be taken care by the Cloud vendor. Though I would put it at a layer above PaaS, it doesn't provide you the feature to tune the resources, but then makes sense if you consider "Ignorance is a Bliss". Cloud Function and Cloud Run are part of Serverless ecosystem in GCP. In fact Cloud Function does provide you a lot of Image/Speech/Text processing capabilities (Libraries from GCP ecosystem) and can be of huge help incase of developing AI related apps in GCP.

This is a good architecture when your application has low demand on your project. It's generally function-based, and you don't have to pay to keep an application up 24 hours a day.

I think the question should be "What are the most common architecture patterns for application development". The tone of the current question is very specialised without context.