5. MONOLITH
▪ Self-contained
▪ Single codebase
▪ Single deploy unit
▪ Easy life for developers
▪ Dependencies are in your code
▪ Single technology stack
6. MONOLITH
▪ All or nothing deploys
▪ Downtimes
▪ Long build times
▪ ~ 0 continuous delivery
▪ Hard to test
20. “It’s perfectly
fine to use sync
HTTP Calls”
▪ Timeouts
▪ Availability
▪ Going back to
coupling?
▪ You can loose
requests
▪ Retries?
21. “It’s perfectly fine to use async HTTP Calls”
▪You’ll have exactly the same issues as with sync calls
▪Distribute load?!
▪You can serve more request
▪You can serve the requests faster
22.
23. HTTP General Notes
▪ Sync by nature
▪ Make a TCP connection for each request
▪ No retry out of the box
▪ No delivery guarantees
▪ Location transparency
▪ Good for public facing APIs
▪ Familiar
▪ Easy to debug
31. Gain vs Loss
▪You don’t lose the requests
▪You can add more handler instances
▪You can ‘apparently’ spread the load
▪You can process more requests
▪ Need to match the request
to the response
▪ You wait for a response =>
sync
33. Messaging
▪Gives you loosely coupled integration
▪Doesn’t require both systems to be up
▪Messages ca be transformed in transit - Enrichers
▪Messaging systems trade consistency for availability
▪You don’t lose messages
▪Involves a Producer and a consumer
40. Gains
• Is a reaction to the problems
of distributed sys
• Process more requests
• Process request faster
• Don’t lose requests
▪ You move the potential
issues to another
subsystem (DB in our case)
▪ Eventual consistency
remains a problem
Loss
41. Gain vs Loss
▪ Connection is scarce
▪ Batch process the message
▪ Use a semaphore to process them in batches
51. Queues
▪Useful for point to point communication
▪Messages are ordered and timestamped
▪Pull-mode
52. Actor model
▪Born from Reactive Programming
▪Actors are processes that encapsulate behavior
▪Actors are more than message consumers
▪Can delegate and create new actors
▪Can supervise children
▪At most once delivery
55. Message Brokers
▪One process sends a message to a named queue or topic
▪One or many consumers
▪Handles connections and disconnections very well
▪Dead-letter queue concept
▪Message Guarantees ( 3 types)
57. AMPQ General Notes
▪ Async by nature
▪ Guaranteed message delivery
▪ At-least once, exactly once, at most once delivery
▪ No DNS resolve
▪ Programmatic routing
▪ Retries out-of-the box
▪ Ack, Nack out of the box
▪ Concept of “channel”
