Dev/Architecture

could not get tsarch working npm uninstall tsarch inspired by https://stackoverflow.com/a/69210603/820837 hacked together my own (in a very rough state) src/architecture.spec.ts import { describe, expect, it } from 'vitest'; import { verifyArchitecture } from './archtest'; describe('Architecture test', () => { it('services should not depend on db', async () => { expect(await verifyArchitecture({ filesFromFolder: 'src/lib/server/services', notDependOnFolder: 'src/lib/server/db' })).toEqual([]); }); it('repositories should not depend on services', async () => { expect(await verifyArchitecture({ filesFromFolder: 'src/lib/server/repositories', notDependOnFolder: 'src/lib/server/services' }))....

Global server load balancing (GSLB) with DNS regional Load Balancers (src: Book_ release it! - Michael Nygard)

Pattern: split deployment view and runtime view Deployment view Transform sources into binaries Transform binaries into deplotments Runtime view Processes running on machines (src: Book_ release it! - Michael Nygard)

x-axis: horizontal duplication scale by cloning eg. load-balander + auto-scaling y-axis: functional decomposition scale by splitting different things eg. monolith -> microservices (compare with Model_ 5 service disintegrators #3 scalability and throughput) z-axis: data partitioning scale by splitting similar things “sharding” eg. split data per product-id (shard 1 = product-id 0 - 99, shard 2 = product-id 100 - 199, …) eg. split data per time (aka “archiving older data”)...

Distinction: events vs messages

Responsiveness time the user is waiting / blocked included: time for the response to return excluded: time continued in the background Performance time for all the work to be done included: time for the response to return time continued in the background excluded: /

Model: Data ownership (in microservice architecture) the owner is the one who writes to the table (1) Pattern: Single Ownership (2) Pattern: Common Ownership solution: create a service around the shared table (3) Pattern: Joint Ownership solution 1: table split pattern solution 2: data domain solution 3: delegation (1) Pattern: Single ownership (data ownership in microservices) (2) Pattern: Common Ownership (data ownership in microservices) solution: create a service around the shared table eg....

Granularity integrators (1) database transactions (2) data dependencies (3) workflow and choreography fault tolerance responsiveness and performance (Model_ 3 types of latency) reliability & data consistency (2) data dependencies axiom: service that writes data, owns it big ball of distributed mud (3) workflow and choreography a) fault tolerance dependency on other service over the network? network problems breaks your service (monolith did not have this problem) b) responsiveness and performance !...

Model: Data access patterns (in microservice architecture) (1) Pattern: interservice communication (2) Pattern: data schema replication (3) Pattern: in-memory replicated cache (4) Pattern: data domain (1) Pattern: interservice communication (data access in microservices) latency network 60-300 ms security secure endpoint re-authorize if expired data query own db query other db (2) Pattern: data schema replication (data access in microservices) keep them in sync: synchronous / asyncronous transaction?...

subjective: (1) service functionality: single responsibility measurable: (2) code volatility: how often does code change (3) scalability and throughput: scale/throughput, startup delay (4) fault tolerance: continue working if one part crashes (5) access control: separate sensitive data to a separate service (1) service functionality what is “single responsibility” is subjective… (2) code volatility (3) scalability and throughput scalability (requests / minute) startup time “mean time to startup (service)” !...