Programming 5
The course introduces the fundamentals of software architecture and of communication between systems. It looks for answers to two questions: how an application can be organised into a single deployment unit or into several independent services, and how these parts can communicate with each other and with the client.
Among the architectures, the monolith, the modular monolith and microservices get dedicated attention; the other styles (layered, hexagonal, microkernel, SOA, service-based, serverless, event-driven) are covered for comparison. The comparison uses the aspects of coupling, deployability, scaling, data handling, consistency, failure handling, and team and operational cost. The communication part leads from synchronous and asynchronous cooperation through the failure handling of remote calls, API styles (REST, RPC and gRPC, GraphQL) and message queues to polling, long polling, SSE and WebRTC, and finally to WebSocket. The material is theoretical and contains no code to run.
Architecture: Views and Trade-offs
The first chapter provides the common vocabulary on which the following chapters build. It distinguishes the code structure, the runtime structure and the deployment structure, names the quality characteristics between which every architecture makes trade-offs, and shows how to look for boundaries in a system. The chapter ends with reading architecture diagrams and recording decisions.
In One Deployment Unit: The Monolith and Its Internal Structures
This chapter covers the architectures in which the system runs as a single deployment unit. It starts with the basic concept of the monolith, then looks at three internal structures: layered, hexagonal and modular, and finally the microkernel built on plug-ins. The chapter shows that "monolith" does not mean disorder, and that the strength of an internal boundary can be designed without a network.
Architectures Split into Services
This chapter compares the styles in which the system consists of several separately running units. SOA, service-based and microservices mean increasingly fine-grained splitting, while serverless is an execution model. The chapter deals in particular with the "microservices = better" misconception and the distributed monolith, and at the end with the criteria of choice and gradual transformation.
Event-Driven Architectures, CQRS and Event Sourcing
The word "event-driven" can mean four different things, so the chapter first separates them. It then looks in detail at event sourcing and CQRS, which often appear together yet are not the same. The chapter ends with the trade-offs: traceability, schema change, eventual consistency, and when not to choose an event-driven structure.
Data and Consistency in a Distributed System
Once the system splits into independent data owners, an operation touching several parts no longer fits into a single database transaction. The chapter starts with data ownership and consistency models, then shows three solutions: the saga, the outbox–inbox pair and the two-phase commit. The aim is not to describe the patterns as recipes, but to understand what each guarantees and what it does not.
Communication Fundamentals: Synchronous and Asynchronous
As soon as the parts of the system run in separate processes, a local call becomes a network call, and new timing and failure situations appear. The chapter starts from the nature of the remote call, distinguishes synchronous and asynchronous cooperation, and then covers the basic tools of latency, contracts and fault tolerance: time limits, retries, idempotency, circuit breakers and security between services. The concrete communication methods of the following chapters build on these foundations.
Synchronous APIs and Entry Points
The chapter compares the main styles of request–response interfaces between services: the REST-style HTTP API, RPC and gRPC, and GraphQL. It then examines how a request reaches the right service: gateway, reverse proxy, BFF, service discovery, load balancing and service mesh. The styles are compared along the same aspects so that the choice can be justified.
Asynchronous Messaging and Webhooks
A message broker can separate the sender from the receiver in time and in availability. The chapter compares the different models of the queue, publish–subscribe and the durable log, then the meaning of acknowledgements and the delivery guarantees, ordering, retrying and the handling of faulty messages, and finally the effect of a slow consumer. The webhook is the HTTP-based variant of asynchronous server-to-server notification, so it closes the chapter.
Updates from the Server Side: Polling, Long Polling, SSE and WebRTC
HTTP is request–response based, and the server cannot speak up to the client by itself. This chapter covers the methods by which data can nevertheless reach the client: from repeated querying (polling) through a held-open request (long polling) and a server-side event stream (SSE) to a direct peer connection (WebRTC). For each method the same aspects are examined, so that before the persistent, two-way WebSocket (chapter 10) it is visible what each solves and what it does not.
WebSocket
WebSocket provides a persistent, two-way message connection between client and server, which is why it stands at the end of the series of communication methods. The chapter starts with how the protocol works, then shows what the application itself has to design: the meaning of messages, reconnection and the resynchronisation of state, scaling and the handling of slow clients, and finally security and troubleshooting. The last lesson compares the methods met so far in one table, and shows where Socket.IO fits among them.
Programming 5
The course introduces the fundamentals of software architecture and of communication between systems. It looks for answers to two questions: how an application can be organised into a single deployment unit or into several independent services, and how these parts can communicate with each other and with the client.
Among the architectures, the monolith, the modular monolith and microservices get dedicated attention; the other styles (layered, hexagonal, microkernel, SOA, service-based, serverless, event-driven) are covered for comparison. The comparison uses the aspects of coupling, deployability, scaling, data handling, consistency, failure handling, and team and operational cost. The communication part leads from synchronous and asynchronous cooperation through the failure handling of remote calls, API styles (REST, RPC and gRPC, GraphQL) and message queues to polling, long polling, SSE and WebRTC, and finally to WebSocket. The material is theoretical and contains no code to run.
Architecture: Views and Trade-offs
The first chapter provides the common vocabulary on which the following chapters build. It distinguishes the code structure, the runtime structure and the deployment structure, names the quality characteristics between which every architecture makes trade-offs, and shows how to look for boundaries in a system. The chapter ends with reading architecture diagrams and recording decisions.
In One Deployment Unit: The Monolith and Its Internal Structures
This chapter covers the architectures in which the system runs as a single deployment unit. It starts with the basic concept of the monolith, then looks at three internal structures: layered, hexagonal and modular, and finally the microkernel built on plug-ins. The chapter shows that "monolith" does not mean disorder, and that the strength of an internal boundary can be designed without a network.
Architectures Split into Services
This chapter compares the styles in which the system consists of several separately running units. SOA, service-based and microservices mean increasingly fine-grained splitting, while serverless is an execution model. The chapter deals in particular with the "microservices = better" misconception and the distributed monolith, and at the end with the criteria of choice and gradual transformation.
Event-Driven Architectures, CQRS and Event Sourcing
The word "event-driven" can mean four different things, so the chapter first separates them. It then looks in detail at event sourcing and CQRS, which often appear together yet are not the same. The chapter ends with the trade-offs: traceability, schema change, eventual consistency, and when not to choose an event-driven structure.
Data and Consistency in a Distributed System
Once the system splits into independent data owners, an operation touching several parts no longer fits into a single database transaction. The chapter starts with data ownership and consistency models, then shows three solutions: the saga, the outbox–inbox pair and the two-phase commit. The aim is not to describe the patterns as recipes, but to understand what each guarantees and what it does not.
Communication Fundamentals: Synchronous and Asynchronous
As soon as the parts of the system run in separate processes, a local call becomes a network call, and new timing and failure situations appear. The chapter starts from the nature of the remote call, distinguishes synchronous and asynchronous cooperation, and then covers the basic tools of latency, contracts and fault tolerance: time limits, retries, idempotency, circuit breakers and security between services. The concrete communication methods of the following chapters build on these foundations.
Synchronous APIs and Entry Points
The chapter compares the main styles of request–response interfaces between services: the REST-style HTTP API, RPC and gRPC, and GraphQL. It then examines how a request reaches the right service: gateway, reverse proxy, BFF, service discovery, load balancing and service mesh. The styles are compared along the same aspects so that the choice can be justified.
Asynchronous Messaging and Webhooks
A message broker can separate the sender from the receiver in time and in availability. The chapter compares the different models of the queue, publish–subscribe and the durable log, then the meaning of acknowledgements and the delivery guarantees, ordering, retrying and the handling of faulty messages, and finally the effect of a slow consumer. The webhook is the HTTP-based variant of asynchronous server-to-server notification, so it closes the chapter.
Updates from the Server Side: Polling, Long Polling, SSE and WebRTC
HTTP is request–response based, and the server cannot speak up to the client by itself. This chapter covers the methods by which data can nevertheless reach the client: from repeated querying (polling) through a held-open request (long polling) and a server-side event stream (SSE) to a direct peer connection (WebRTC). For each method the same aspects are examined, so that before the persistent, two-way WebSocket (chapter 10) it is visible what each solves and what it does not.
WebSocket
WebSocket provides a persistent, two-way message connection between client and server, which is why it stands at the end of the series of communication methods. The chapter starts with how the protocol works, then shows what the application itself has to design: the meaning of messages, reconnection and the resynchronisation of state, scaling and the handling of slow clients, and finally security and troubleshooting. The last lesson compares the methods met so far in one table, and shows where Socket.IO fits among them.