(micro)Service Orientened Architecture

Microservices

Properties

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations.

Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response.

Sharing useful and, above all, battle-tested code as libraries encourages other developers to solve similar problems in similar ways yet leaves the door open to picking a different approach if required.

Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible.
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/partial-failure-strategies
https://blog.risingstack.com/designing-microservices-architecture-for-failure/

 verifies that a system meets external requirements and achieves its goals, 
 testing the entire system, from end to end

state = foldL(currentState, history, eventToApply)

advantages

Reifies state changes - in built audit for state changes with events in its history
tracks application state like what git log does. so can replay any event at particular time to get the same state change
handles idempotency as an effect of any event (service needs to designed that way - lot of work :) )
filter duplicate event
DDD, Aggregates

disadvantages

loads of work keep tracking of the event-consumer offset (unless some neat libraries used)
loads of work handling a case when there are multiple instances of the same event-consumer exist, and both try to consume the events and update the consumer offset. (Idempotency should handle it but again need to handle that they don't publish something duplicate event)
idempotency itself might be hard to implement sometimes
also, change in event structure might effect the existing consumers