Update mission-statement.md

docs/general/mission-statement.md

@@ -8,41 +8,41 @@
 
 `Microbus` conforms to [industry standards](#industry-standards) and [interoperates](#interoperability) smoothly with existing systems.
 
-## Microbus
+### Microbus
 
 The name `Microbus` stems from the fact that `micro`services communicate with each other over a messaging `bus`.
 The bus enables both the [request/response](../blocks/unicast.md) and [publish/subscribe](../blocks/multicast.md) patterns of communications
 and is also responsible for load balancing and service discovery.
 
-## Holistic
+### Holistic
 
 Holistic _adj_ /hō-ˈli-stik/ : characterized by the belief that the parts of something are interconnected and can be explained only by reference to the whole.
 
-## Open Source Framework
+### Open Source Framework
 
 `Microbus` is essentially a software library you use as a foundation for your microservice solution.
 And because it is open sourced, you can feel confident betting your business on it.
 
-## SDLC
+### SDLC
 
 `Microbus` delivers a dynamic range of tools designed to optimize the full SDLC of microservice solutions.
 
-#### Develop
+##### Develop
 
 Run and debug an entire solution comprising a multitude of microservices on your [local development](../tech/local-dev.md) machine, just as easily as if it were a monolith.
 
 Speed up development with [code generation](../blocks/codegen.md).
 
-#### Test
+##### Test
 Spin up the actual downstream microservices along with the microservice being tested into a single process and execute full live [integration tests](../blocks/integration-testing.md)
 
-#### Deploy
+##### Deploy
 From a [local development](../tech/local-dev.md) machine to a multi-region cloud deployment, `Microbus`'s [adaptable topology](../blocks/topology.md) grows with your needs. No code change required.
 
-#### Operate
+##### Operate
 Observe system internal with the help of [distributed tracing](../blocks/distrib-tracing.md), metrics dashboards, structured logging and [error capture](../blocks/error-capture.md).
 
-## Why Microservices?
+### Why Microservices?
 
 Microservices are the architecture best suited to deal with the technical and organizational challenges of a growing business.
 * Scale the engineering organization
@@ -52,22 +52,22 @@ Microservices are the architecture best suited to deal with the technical and or
 * Stay agile and adaptable to change
 * Harden your solution to better deal with failures
 
-## At Scale
+### At Scale
 
 `Microbus` helps you build and operate large solutions comprising dozens or even hundreds of microservices
 by addressing both the engineering and the operational challenges inherent in such complex systems.
 Unlike many other frameworks, it is not merely a helper library for coding of single microservices.
 
-## Curated OSS
+### Curated OSS
 
 `Microbus` is powered by a small curated set of best-in-class [OSS](../blocks/layers.md#oss) technologies integrated to work together in unison.
 The small number of moving parts keeps the learning curve short and operational cost and complexity low.
 
-## Tooling
+### Tooling
 
 A powerful [code generator](../blocks/codegen.md) takes care of most of the repetitive mundane work, freeing engineers to do meaningful work and deliver business value faster.
 
-## Best Practices
+### Best Practices
 
 `Microbus` implements best practices that pave the road and steer engineers away from common pitfalls.
 
@@ -78,7 +78,7 @@ A powerful [code generator](../blocks/codegen.md) takes care of most of the repe
 * Centralized configuration
 * Distributed cache that is isolated to each microservice, not a centralized global cache
 
-## Elevated Engineering Experience
+### Elevated Engineering Experience
 
 In `Microbus`, microservices are not large memory-gobbling processes but rather compact worker goroutines that ultimately consume messages from a queue.
 This quality allows running, testing and debugging an entire solution comprising a multitude of microservices on a [local development](../tech/local-dev.md) machine.
@@ -90,7 +90,7 @@ Observability tools such as [distributed tracing](../blocks/distrib-tracing.md),
 
 `Microbus`'s functionality is exposed through a [simple API](../tech/encapsulation.md) that is easy to learn. An engineer can get up to speed quickly without having to learn all the internals first. This principle of simplicity is also carried over to `Microbus`'s runtime where the small number of moving parts reduced operational complexity.
 
-## Conventional Practice
+### Conventional Practice
 
 The conventional practice relies on many sophisticated systems to work together reliably, increasing the failure risk profile.
 The added complexity requires a high level of expertise from the engineering and operations teams resulting slower ramp up time of new engineers.
@@ -109,35 +109,35 @@ It also slows down day-to-day development because the solution cannot be easily
 * Separate system for caching (e.g. Redis, memcached)
 * K3s for local development
 
-## Runtime Substrate
+### Runtime Substrate
 
 All microservices running on `Microbus` comply with the same set of rules for [unicast](../blocks/unicast.md) or [multicast](../blocks/multicast.md) communications, [configuration](../blocks/configuration.md), observability, and more. This consistent behavior makes it easier to reason about the accuracy of the system, guaranteeing smooth interoperability, straightforward maintainability and verifiable stability. 
 
-## Performance
+### Performance
 
 Benchmarks indicate `Microbus` is able to process upward of 60,000 req/sec on a single 10-core CPU.
 
-## Reliability
+### Reliability
 
 Reliable communication is an imperative quality of any distributed system. In `Microbus`, microservices communicate with each other over a messaging bus. Each microservice connects to the bus over a persistent bi-directional multiplexed connection that is monitored constantly and kept alive with automatic reconnects if required. Locality-aware routing, an ack of fail fast pattern and graceful shutdowns further enhance the reliability of communications.
 
 It is also imperative that a distributed system remains online at all times. `Microbus` achieves that by capturing all errors and panics so that malfunctioning microservices do not crash.
 
 As a framework, `Microbus` is expected to run business-critical solutions. It is thoroughly-tested by hundreds of unit tests.
 
-## Horizontal scalability
+### Horizontal scalability
 
 Components at all [layers](../blocks/layers.md) of `Microbus` are horizontally scalable. There is no single points of failure or bottlenecks. At the transport layer, the messaging bus forms a full mesh so that any message traverses no more than two nodes regardless of the size of the cluster. At the application layer, dynamic discovery makes it trivial to add replicas of microservices and scale the solution.
 
-## Industry Standards
+### Industry Standards
 
 `Microbus` conforms to industry standards.
 
 * Communication over the bus conforms to the HTTP protocol
 * Observability data is pushed to OpenTelemetry collectors
 * [OpenAPI](../blocks/openapi.md) documents are automatically created for each microservice
 
-## Interoperability
+### Interoperability
 
 Because `Microbus` conforms to the familiar HTTP protocol for service-to-service communications, it is a snap to process incoming HTTP requests from non-`Microbus` microservices or from JavaScript clients, or conversely make an outbound call to non-`Microbus` microservices or third-party web services.