Architecture Principles

Microservices / frontends

General rules to decide if we need one more microservice/frontend:

Pros
1. it will have one and only one team as the owner
2. it has few connections with another service (<10% of the incoming or outgoing communications are external API calls, the rest is direct function calls inside the service's runtime)
3. the existing service can not fit the technical restrictions (e.g., too many resources in CloudFormation)
4. the current service already has more than 25 models
Cons
1. we split one service into several smaller ones, which will still belong to the same team
2. we don't clearly understand the scope of the service
If any given solution requires less services to be modified, ceteris paribus, it's a better solution than the others. For example, we need to update some record in Service B when a record in Service A was updated, and Service A knows that records in Service B need to be updated.
```
// bad (two services affected)

1. Service A broadcasts an event
2. Service B subscribes on the event and updates its records internally

// good (one service affected)

1. Service A updates records in Service B via direct API/lambda call
```