Distributed systems involve loosely coupled nodes connected over a network that share distributed memory. This architecture allows for horizontal scaling but introduces complexity around communication, errors, security, and coordination across nodes. While monolithic architectures can suffer from premature optimization, distributed systems require high skills from developers to effectively handle asynchronous communication, errors, monitoring, and other challenges. Ultimately, there is no single right way to design distributed systems - it depends on balancing performance, costs, and complexity for the particular application.

1. Distributed systems
beauty and the beast
MICHAŁ ŁUKASZEWSKI, INTEL

3. Roadmap
Glossary
A real life
Conclusions

4. Glossary
WHAT A „DISTRIBUTES SYSTEM” IS?

5. Loosely coupled,
service oriented architecture
„Nodes”
Distributed memory
Communication through network

7. Why we distributed systems
AND WHAT HAPPNES THEN

8. Hype Driven Development

10. Monolith architecture

14. Premature optimization

15. Overengineering
https://twitter.com/ziobrando/status/741186560373186560

19. DRY is not about identical chunks of bits or characters in different places.
DRY aims at not repeating domain concepts

20. What happens then?

21. Cyclomatic complexity

22. Cyclomatic complexity

23. Monolith architecture

24. Monolith Distributed architecture

25. Monolith Distributed architecture

27. Costs

28. Maintenance costs
Logs (distributed)
Monitoring
Availibity
Access policies
Backups
UPDATES!

29. Perfomance vs. costs
HIGH SKILLS OF DEVELOPERS

30. The true problem is...
DATA

32. Calling a remote system

35. Async
Error handling (and their are asynchronous and distributed)
Monitoring a progress of request flow
Security
QoS
IoC (on the architecture level)
Dealing with past events
Skills of developers and programmers
Callback hell

36. Security
Sign in/ssl/keys (we know everything about this)
How we can confirm that data from queue are safe and
trustable?
What we can do if remote systems unexpectably sends
to us many strange requests (as part of the botnet)
Neverending story...

38. Conclusions
IS THERE IS RIGHT WAYS?

44. Design and maintenance of distributed
systems is

45. Design and maintenance of distributed
systems is

46. Design and maintenance of distributed
systems is

47. Design and maintenance of distributed
systems is

52. Literatura
• https://martinfowler.com/ieeeSoftware/coupling.pdf
• https://thenewstack.io/dockercon-europe-adrian-
cockcroft-on-the-state-of-microservices/
• https://jrtrivedi.blogspot.com/2016/03/difference-
between-loosely-coupled-and.html
• https://speakerdeck.com/mat3u/domain-events-czyli-
jak-radzic-sobie-z-rzeczywistoscia
• https://speakerdeck.com/ulff/event-sourcing-in-php
• http://blog.best.net.pl/16-key-points-wydajnosc-w-
budowaniu-aplikacji-internetowych/
• https://www.linkedin.com/profile/portfolio?id=31205064
&authType=name&authToken=YnLc&mediaID=51178139
&trk=landing_share
• http://danielwhittaker.me/2014/09/29/handling-
concurrency-issues-cqrs-event-sourced-system/
• https://www.youtube.com/watch?v=l2vQqJW64DQ