|
1 | 1 | = Communication Patterns |
2 | | -:figures: 01-system-design |
| 2 | +:figures: 01-system-design/communication-patterns |
3 | 3 |
|
4 | 4 | A summary of how you can combine patterns and tools. Keep in mind |
5 | 5 | that this is just a recommendation. you might have your own |
@@ -145,3 +145,63 @@ consider both the benefits and drawbacks. |
145 | 145 | When you expect high traffic and concurrency with fewer computational |
146 | 146 | resources, the reactive paradigm can improve the application’s scalability, resil- |
147 | 147 | ience, and cost-effectiveness at the expense of a steeper initial learning curve. |
| 148 | + |
| 149 | +When developing reactive microservices, it is not always obvious when to use non-blocking synchro- |
| 150 | +nous APIs and when to use event-driven asynchronous services. In general, to make a microservice |
| 151 | +robust and scalable, it is important to make it as autonomous as possible, for example, by minimizing |
| 152 | +its runtime dependencies. This is also known as loose coupling. Therefore, the asynchronous mes- |
| 153 | +sage passing of events is preferable over synchronous APIs. This is because the microservice will only |
| 154 | +depend on access to the messaging system at runtime, instead of being dependent on synchronous |
| 155 | +access to a number of other microservices. |
| 156 | +There are, however, a number of cases where synchronous APIs could be favorable. For example: |
| 157 | + |
| 158 | +• For read operations where an end user is waiting for a response |
| 159 | +• Where the client platforms are more suitable for consuming synchronous APIs, for example, |
| 160 | +mobile apps or SPA web applications |
| 161 | +• Where the clients will connect to the service from other organizations – where it might be |
| 162 | +hard to agree on a common messaging system to use across organizations |
| 163 | + |
| 164 | +[tabs] |
| 165 | +====== |
| 166 | +CaveatEmptor:: |
| 167 | ++ |
| 168 | +
|
| 169 | +Cities API:: |
| 170 | ++ |
| 171 | +
|
| 172 | +Multiplication microservices:: |
| 173 | ++ |
| 174 | +
|
| 175 | +Microservices with Spring Boot 3 and Spring Cloud:: |
| 176 | ++ |
| 177 | +However, one major concern was identified . Updating (creating or deleting) a composite |
| 178 | +entity—an entity whose parts are stored in a number of microservices—using synchronous APIs can |
| 179 | +lead to inconsistencies, if not all involved microservices are updated successfully. This is, in general, |
| 180 | +not acceptable. This leads us into reactive microservices, where we will look into why and how to build |
| 181 | +reactive microservices, that is, microservices that are scalable and robust. |
| 182 | ++ |
| 183 | +For the system landscape in this book, we will use the following: |
| 184 | ++ |
| 185 | +• The create, read, and delete services exposed by the product composite microservice will be |
| 186 | +based on non-blocking synchronous APIs. The composite microservice is assumed to have |
| 187 | +clients on both web and mobile platforms, as well as clients coming from other organizations |
| 188 | +rather than the ones that operate the system landscape. Therefore, synchronous APIs seem |
| 189 | +like a natural match. |
| 190 | +• The read services provided by the core microservices will also be developed as non-blocking |
| 191 | +synchronous APIs since there is an end user waiting for their responses. |
| 192 | +• The create and delete services provided by the core microservices will be developed as |
| 193 | +event-driven asynchronous services, meaning that they will listen for create and delete events |
| 194 | +on topics dedicated to each microservice. |
| 195 | +• The synchronous APIs provided by the composite microservices to create and delete aggregated |
| 196 | +product information will publish create and delete events on these topics. If the publish opera- |
| 197 | +tion succeeds, it will return with a 202 (Accepted) response; otherwise, an error response will |
| 198 | +be returned. The 202 response differs from a normal 200 (OK) response – it indicates that the |
| 199 | +request has been accepted, but not fully processed. Instead, the processing will be completed |
| 200 | +asynchronously and independently of the 202 response. |
| 201 | ++ |
| 202 | +images::{figures}/Microservices-with-Spring-Boot-and-Spring-Cloud-communication-pattern.png |
| 203 | +
|
| 204 | +Polar Book Shop:: |
| 205 | ++ |
| 206 | +
|
| 207 | +====== |
0 commit comments