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
22. “It’s perfectly
fine to use sync
HTTP Calls”
•Timeouts
•Availability
•Going back to coupling?
•You can loose requests
•Need to have a retry
mechanism
23. “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
24.
25. HTTP General Notes
▪ Sync by nature
▪ Make a TCP connection for each request
▪ No retry out of the box
▪ No delivery guarantees
▪ No routing without a Service Discovery or configuration
▪ Good for public facing APIs
▪ Familiar
▪ Easy to debug
33. 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
35. Messaging
▪Gives you loosely coupled integration
▪Doesn’t require both systems to be up
▪Messages ca be transformed in transit
▪Messaging systems trade consistency for availability
▪You don’t loose messages
42. 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
43. Gain vs Loss
▪ Connection is scarce
▪ Batch process the message
▪ Use a semaphore to process them in batches
55. Queues
• Useful for point to point communication
• Messages are ordered and timestamped
• Pull-mode
56. Actor model
▪Actors are processes that encapsulate behaviour
▪Actors are more than message consumers
▪Can delegate and create new actors
▪Can supervise children
▪At most once delivery
57. Message Brokers
▪One process sends a message to a named queue or topic
▪One or many consumers
▪Handles connections and disconnections very well
▪One-way data flow or request/response model –”ReplyTo”
▪Dead-letter queue concept
59. 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”
