Event-driven, hexagonal, micro-services… we can quickly trim down the options to a few\ncandidates. We will then explore, evaluate and select one of them.
\n--- excerpt ---
\nThis post is part of a 3-subseries in which we design the high-level architecture for Cryptomate.
\n\n\n\n
\n- Modules and components.
\n- Exploring patterns (this post).
\n- Critical points.
\n
Given the task at hand, we can quickly trim down the options to a few candidates:
\nWe will explore, evaluate and eventually select one of them.
\nThis architecture pattern revolves around reacting to events by orchestrating the workflow\nas a chain of events flowing through event processors, under possible supervision by a\nmediator.
\nIt enables asynchronous, distributed workflows, which could power Cryptomate:
\n![\"Event-driven](\"/files/eventdriven-6afb461fefb45c1cfd4b5b3a6878dfe6.png\")
The main selling points of this architecture pattern are excellent agility and deployment,\nas event processors are standalone and self-contained, and good performance through scalability\nas processors can be instantiated several times over new resources to accommodate demand.
\nThis comes at the cost of difficult development and testing. Failures in event processors\nare tricky to diagnose and the fully asynchronous nature of the workflow is hard to reason\nabout. As for testing, testing single event processors is easy, but end to end testing is hard.
\nThis architecture pattern, also called the ports & adapters pattern, designs the system by\ndefining a bound between the inside and the outside of the application. Inside is the business\nlogic, working in an abstract environment. Every domain-level feature or functionality it\nrequires is defined by a port, that is, an abstract slot in the application.\nOn the outside, adapters support specific ports, allowing one to “plug” an external\nservice onto the port, providing the feature.
\n![\"Hexagonal](\"/files/hexagonal-34596ae6cc8251aa4357500a509f8195.png\")
By encapsulating all communications, this pattern facilitates interchangeability of both\ninput and output channels. This could power Cryptomate like this:
\nThe main selling points of this pattern are maintainability and testability. By enforcing\nthat all communications go through ports and adapters, this pattern makes it easy to adapt\nthe system to changing third parties. Say, supporting new brokers. This can be leveraged to\ntest components by providing them adapters that feed them test data and trace their reaction.
\nThis architecture pattern comes as a simplification of the famous Service-Oriented\nArchitecture or SOA,\ndropping orchestration and complex routing in favor of a lightweight message broker,\nor no broker at all.
\nMicro-services revolve around organizing the application as a set of small, standalone,\nindependently-deployed service components. Each component performs a self-contained business\nfunction, which it exposes using a standard interface.
\n![\"Micro-services](\"/files/microservices-0e67bd2c8ec432996b9d3ffc48b6766b.png\")
Cryptomate could be designed as a set of micro-services like this:
\nThe main selling points of this pattern are scalability and continuous delivery, as\nservice components can be easily multiplied to handle increasing load, and their\nindependently-deployed, self-contained nature allows incremental deployment. Testability is\nexcellent too, as each service component can be tested in isolation.
\nOn the other hand, being a distributed architecture, it shares the caveats of complexity\nof event-driven architectures. Performance also tends to be poor, due to tasks requiring\na lot of communications to distributed nodes. This can be counter-balanced by careful\nimplementation, but does not come naturally with the pattern.
\nThis architecture pattern revolves around creating a basic core system, which is then\naugmented with plugin modules to create a fully functional system. The core system acts\nas a simple framework, capable of locating plugins and managing them. It typically has but\na very simple knowledge of business logic, delegating all details to the plugins.
\n![\"Micro-kernel](\"/files/microkernel-6370062dbf51f6bc5936e2b78bdf4fd5.png\")
Cryptomate could be designed as a micro-kernel like this:
\nThe main selling points of this pattern are excellent agility and testability. By adding\nand removing plugins, the system can easily adapt, and plugins can be tested in isolation.
\nOn the other hand, this pattern does not address scalability at all, as the run-time is\nmonolithic even though its design is not. Also, designing a solid plugin system, capable\nof handling the diverse contracts that may apply to all the facets of the business logic,\nis difficult.
\nHere is what we have so far:
\n| Attribute | \nEvent-driven | \nHexagonal | \nMicro-services | \nMicro-kernel | \n
|---|---|---|---|---|
| Testability | \n\n | \n | \n | \n |
| Maintainability | \n\n | \n | \n | \n |
| Ease of development | \n\n | \n | \n | \n |
| Performance | \n\n | \n | \n | \n |
| Availability | \n\n | \n | \n | \n |
| Scalability | \n\n | \n | \n | \n |
Quality Attributes are ordered from the most valued by our requirements to the least valued.\nI intentionally left out quality attributes that are mostly unaffected by this choice.
\nWe can clearly eliminate the event-driven architecture immediately.1\nNow, the hexagonal model seems like a good fit, but is lacking on the availability and\nscalability side. Also, it does not provide a model for abstracting out business logic,\nwhich we need to build a versatile strategy engine.
\nWe could alleviate those weaknesses though, by:
\nHere is a tentative high-level design leveraging this combination:
\n![\"Cryptomate](\"/files/composed-4f1a85618d2bd380a1427d99cf4bf0aa.png\")
This gives us a hybrid architecture: an hexagonal architecture where some adapters use\nmicro-services. Thus, the performance/scalability trade-off can be postponed\nto integration-time, making our system equally potent at servicing large-scale farm of\nstrategies and performance-critical, tailored, single-user setups.
\nAs a last step, we should double-check with our requirements that this\ntentative architecture has a straightforward path for all of them. For instance, adding\nsupport for a new market data provider can be done by creating a new adapter, which, in a\nproperly structured hexagonal pattern, will not change existing code.
\nI did check all of them, feel free to do it on your side as an exercise, and send me\nfeedback if you find I missed something.
We created our initial idea of the system's architecture. We validated all known scenarios\nfit into our idea. There are still a few critical areas that need to\nbe refined.
\n\nNote the event-driven model is a bad fit mostly because I am doing this project alone, which pushes ease of development and testability high up the list; a larger team would probably overcome those difficulties and pick an event-driven model for its performance.
\n↩\n