remove diagrams on resource pages add linking to architecture page

Author: HomelessDinosaur

docs/apis.mdx

@@ -6,18 +6,7 @@ description: 'Building HTTP APIs with Nitric'
 
 Nitric has built-in support for web apps and HTTP API development. The `api` resource allows you to create APIs in your applications, including routing, middleware and request handlers.
 
-## Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-
-    A(Admin Api)-->B(Service A);
-    A-->C(Service B);
-    D(Public Api)-->B(Service A)
-```
-
-> An API can route to many nitric services, and services can handle many APIs.
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/apis).
 
 ## Creating APIs
 

docs/keyvalue.mdx

@@ -6,6 +6,8 @@ description: 'Key value stores'
 
 Nitric provides functionality for provisioning and interacting with persistent key/value stores.
 
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/keyvalue).
+
 ## Definitions
 
 ### Key Value Store

docs/messaging.mdx

@@ -14,19 +14,7 @@ A topic is a named resource where events can be published. They can be thought o
 
 Topics are often the first choice for communication between services, since they offer stateless, scalable and highly decoupled communication.
 
-### Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-    classDef edgeLabel line-height:1.2;
-
-    A(Topic)-- on message -->B(Message Service);
-    C(Publisher Service) -- publish message --> A;
-    D(Publisher Batch Service) -- publish message --> A;
-```
-
-`Services` can both publish and subscribe to topics. `Batch Services` may only publish messages.
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/topics).
 
 ### Subscriptions
 
@@ -378,6 +366,8 @@ Queues are another option for asynchronous messaging. Unlike [topics](#topics),
 
 This makes queues ideal for batch workloads, often paired with [schedules](/schedules).
 
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/queues).
+
 <Note>
   Queue disambiguation: Some systems and cloud providers use the term "queue" to
   refer to a messaging broker with features akin to a topic (i.e. they can push

docs/schedules.mdx

@@ -10,16 +10,7 @@ The `schedule` resource lets you define named schedules, including their frequen
 
 If you're looking for a way to perform once-off work at some point in the future, use [delayed messaging](./messaging#delayed-messaging) instead of schedules.
 
-## Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-
-    A(Weekly Schedule)-->B(Service A);
-```
-
-> Schedules can be used to trigger a single service at a set cadence
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/schedules).
 
 ## Creating schedules
 

docs/secrets.mdx

@@ -8,18 +8,7 @@ Nitric Secrets simplifies the secure storage, updating, and retrieval of sensiti
 
 Alternatively, you can choose to store these values as environment variables. Learn more about it [here](/reference/env).
 
-### Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-    classDef edgeLabel line-height:1.2;
-
-    B(Service)-- access/put secret -->A(Secret);
-    C(Batch Service) -- access/put secret --> A;
-```
-
-Both `Services` and `Batch Services` can access and put secrets values.
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/secrets).
 
 ## Definitions
 

docs/sql.mdx

@@ -6,6 +6,8 @@ description: 'SQL databases'
 
 Nitric provides functionality for provisioning and interacting with SQL databases.
 
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/sql).
+
 <Note>
   SQL databases are currently in preview and only support PostgreSql deployed to
   AWS using the <br className="hidden lg:block" />

docs/storage.mdx

@@ -6,19 +6,7 @@ description: 'Working with files and storage in Nitric'
 
 Nitric provides storage support for securely storing and retrieving large files in the cloud.
 
-## Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-    classDef edgeLabel line-height:1.2;
-
-    A(Bucket)-- on write -->B(Bucket Handler Service);
-    C(Bucket File Service) -- read/write/delete files --> A;
-    D(Image Processing Batch Service) -- read/write/delete files --> A;
-```
-
-A `Service` can both interact file files in a `Bucket` and receive notifications when files are written or deleted. A `Batch Service` can only interact with files on a bucket but cannot subscribe to file changes.
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/buckets).
 
 ## Definitions
 

docs/websockets.mdx

@@ -6,28 +6,14 @@ description: 'Connect and manage websockets with Nitric'
 
 Nitric provides support for serverless websockets. This feature allows you to connect client applications to your Nitric services using websocket gateways such as AWS APIGateway.
 
+If you're interested in the architecture, provisioning, or deployment steps, they can be found [here](/architecture/websockets).
+
 <Note>
   Projects with websockets will only be deployable to AWS at the moment. If you
   require support for additional clouds let us know:
   https://github.com/nitrictech/nitric/issues
 </Note>
 
-## Architecture
-
-```mermaid
-graph LR;
-    classDef default line-height:1.2;
-    classDef edgeLabel line-height:1.2;
-
-    A(Websocket Gateway)-- on connect -->B(Connection Handler Service);
-    A -- on disconnect --> B;
-    A -- on message --> C(Message Handler Service);
-    C -- send message --> A;
-    D(Batch Service) -- send message --> A;
-```
-
-A `Service` can both receive and send messages to a `Websocket`, `Batch Services` may only send message to a `Websocket`.
-
 ## Listening for events
 
 There are three events that must be defined to deploy a valid websocket implementation. These are `connect`, `disconnect` and `message`.