How do you define the required architectural characteristics?
- Consider actors (including system)
- Consider the actions that each actor must take
- Create components based upon these actions
- Consider what architectural characteristics each component must have e.g. elasticity, scalability, reliability, availability
- If the system can manage with a single set of architectural characteristics then a monolith offers many advantages
- If the components have differing characteristics, a distributed architecture may be better
What are some fallacies of distributed computing?
- The network is reliable. It’s not, the more a system relies on it (like microservices), the potentially less reliable it is
- Latency is zero. It’s not e.g. a REST remote access call is always slower than a local in memory method call. What’s the average round trip latency for a RESTful call in your production environment? 60 milliseconds is very good but if you chain 10 services that’s 600 milliseconds. And what is the latency for the 95th and 99th percentile? It’s usually the long tail latency that kills performance in a distributed architecture
- Bandwidth is infinite. It’s not e.g. microservices uses significant bandwidth thus impacting latency and reliability
- The network is secure. Distributed systems have a much bigger surface area for threats having to secure every endpoint
- Transport cost is zero. Its not - distributed architectures cost significantly more than monoliths primarily due to increased needs for additional hardware e.g. servers, gateways, firewalls etc
Other distributed system considerations
- issues can be harder to debug as there are a lot more logs
- In monoliths with one db, data tends to be updated and consistent. Distributed systems rely on eventual consistency- that is that separate units will at some point be in a synchronised state following transactions
What is a layered architecture
Presentation (api) layer
Business (services) layer
Persistence (model) layer
Database layer
Separation of concerns by technical role instead of by domain. Layers are isolated and requests must go down through each layer - meaning that changing a layer doesn’t impact other layers providing that the contract is unchanged. For simple requests that require no logic but go down and back up through every layer, this is inefficient- impacting memory consumption and performance. If most requests are like this, make the layers open.
Good for small, simple applications and is cheap / easy to make as simple for devs. Good starting point.
Benefits (cost and simplicity) diminish with scale as it becomes a complex monolith.
Poor for scalability and elasticity as hard to scale single services within a monolith - have to use complex multithreading / parallel processing
What is a service-based architecture
A hybrid microservices architecture. Although it’s distributed, it doesn’t have the same complexity and cost as other distributed styles like microservices.
Distributed macro layered structure:
1. Separately deployed user interface layer
2. Multiple separately deployed remote coarse-grained services
3. Monolithic database layer
Multiple instances of a service can exist for scalability but require load balancing. Easier than with a monolith.
Central shared database allowing services to leverage SQL queries and joins like a monolith along with commit and rollback transaction functionality. But more risk when changing dB schema as could impact multiple services. Having a single shared library of entity objects means that any change requires a change and redeployment for all services. Logically partitioning the the database into federated shared libraries reduces the impact of change.
The DB and interface layers can then be split becoming service scoped - moving towards microservices
Domain services are typically designed using a layered architecture - API, business, and persistence layers. They are much coarser-grained than microservices so better for data integrity (don’t rely on eventual consistency) but more coupling so changes need to be tested more. Less network traffic so more reliable but harder to scale.
Good for domain driven design and services are domain-scoped.
What is an event driven architecture?
Distributed and asynchronous. For highly scalable, high performance applications. The system reacts and takes action based on particular events.
Made up of decoupled event processing components that asynchronously receive and process events.
Two topologies:
- Mediator topology for control over the workflow of an event process, or
- Broker topology for a higher degree of responsiveness and dynamic control over processing an event
Broker topology - no central event mediator. Instead, the message flow is distributed across the event processor components in a chain-like broadcasting fashion. Good for simple events that don’t need central event coordination.
Initiating event -> event channel -> accepted by event processor -> processes event and sends processing event to hand off the event to the next event processor that listens and reacts if necessary, then sends processing event on again -> carries on along the chain until no processors are interested
Event broker components are usually federated into domain-based cluster instances
Async fire & forget broadcasting. Once an event processor hands off the event, it is no longer involved and can react to new events
Each event processor can be scaled individually
Error handling is difficult if failure occurs in the chain as no one system is aware (no mediator monitoring and controlling). So no ability to restart the transaction and recover
Mediator topology - has a central event mediator to manage and control event workflows and coordinate multiple event processors
Initiating event -> event queue -> accepted by event mediator -> mediator generates corresponding processing events and sends to queues for dedicated event channels in a point-to-point fashion -> processors process events and respond to mediator
Typically multiple mediators split by domain - increases performance and throughput. Reduces single point of failure issue of havi g only one mediator.
Mediators control and manage state allowing for error handling, recoverability, and restart capabilities.
However, it’s difficult to dynamically model the processing of complex events. Must scale mediators along with event processors. Event processors are not as highly decoupled with the mediator topology. Worse performance as more steps.
Broker topology = high performance and scalability
Mediator topology = better workflow control and error handling
Asynchronous Capabilities - Event Driven Architecture relies solely on async communication for both fire-and-forget processing (no response required) as well as request/reply processing (response required from the event consumer). Async communication can dramatically increase the overall responsiveness of a system. When the user doesn’t need a response, why make them wait. The main issue with async is error handling and data loss
Preventing data loss - big issue for async comms e.g messages getting dropped / lost. Persisted message queues support guaranteed delivery. When the message broker receives the message it stores it in memory for fast retrieval and in physical data store.
Request-Reply - none async e.g. if a confirmation number is needed when an order is placed it must be synchronous. For this architecture, this is done with request-reply messaging. Each event channel has 2 queues - request and reply. Request is async then the message producer does a blocking wait.
Request-based or event-based:
- Request based: For well-structured, data-driven requests when certainty and control over workflow is needed (e.g. getting user profile data)
- Event-based: For flexible, action-based events that require high responsiveness and scale, with complex and dynamic user processing
Hybrid event-driven architectures: e.g. microservices and space-based architectures can leverage event-driven architecture to help remove bottlenecks and improve user responsiveness
Ratings:
- bad for simplicity and testability
- good for performance and scalability
Moving from a monolith…
- Decomposition: Break down the monolithic application into smaller, manageable services or modules based on business functionality or domain boundaries.
- Microservices: Adopt a microservices architecture where each service is responsible for a specific business capability and can be developed, deployed, and scaled independently.
- APIs: Implement well-defined APIs for communication between services, often using REST or gRPC protocols, ensuring loose coupling and clear contracts.
- Containerization: Use container platforms like Docker to package services with their dependencies, ensuring consistent deployment across environments.
- Orchestration: Adopt container orchestration tools like Kubernetes to manage, scale, and maintain microservices in a distributed environment.
- Continuous Integration/Continuous Deployment (CI/CD): Implement CI/CD pipelines to automate testing, integration, and deployment processes, facilitating rapid and consistent releases.
- Service Discovery: Implement service discovery mechanisms to allow services to find and communicate with each other dynamically in a distributed environment.
- Resilience: Design services for fault tolerance, using patterns like circuit breakers, retries, and fallbacks to handle failures gracefully.
- Data Decentralization: Move from a centralized database to decentralized databases, where each service owns its data and database schema.
- Monitoring and Observability: Implement comprehensive monitoring, logging, and tracing solutions to gain visibility into the health and performance of individual services in the distributed system.
What is Domain Driven Design?
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.
It is all about trying to make your software a model of a real-world system or process.
What is gRPC
In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types.
gRPC clients and servers can run and talk to each other in a variety of environments, for example, you can easily create a gRPC server in Java with clients in Go, Python, or Ruby.
By default, gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON).
