backend-system: doc tweaks

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/backend-system/architecture/01-index.md

@@ -1,7 +1,7 @@
 ---
 id: index
 title: Backend System Architecture
-sidebar_label: System Architecture
+sidebar_label: Overview
 # prettier-ignore
 description: The structure and architecture of the new Backend System and its component parts
 ---

docs/backend-system/architecture/06-modules.md

@@ -43,7 +43,3 @@ export const catalogModuleExampleCustomProcessor = createBackendModule({
 Notice that we're placing the extension point we want to interact with in the `deps` option, while also depending on the logger service at the same time. When initializing modules we can depend on both extension points and services interchangeably. You can also depend on multiple extension points at once, in case the implementation of the module requires it.
 
 It is typically best to keep modules slim and to each only add a single new feature. It is often the case that it is better to create two separate modules rather than one that provides both features. The one limitation here is that modules can not interact with each other and need to be self contained.
-
-## HTTP Handlers
-
-Since modules have access to the same services as the plugin they extend, they are also able to register their own HTTP handlers. For more information about the HTTP service, see [core services](../core-services/01-index.md). When registering HTTP handlers, it is important to try to avoid any future conflict with the plugin itself, or other modules. A recommended naming pattern is to register the handlers under the `/modules/<module-id>` path, where `<module-id>` is the kebab-case ID of the module, for example `/modules/example-custom-processor/v1/validators`. In a standard backend setup the full path would then be `<backendUrl>/api/catalog/modules/example-custom-processor/v1/validators`.