diff --git a/README.md b/README.md
index cd38b846..1322c246 100644
--- a/README.md
+++ b/README.md
@@ -43,60 +43,6 @@ Join us to discuss, learn and contribute:
By default go-micro only provides a few implementation of each interface at the core but it's completely pluggable. There's already dozens of plugins which are available at [github.com/micro/go-plugins](https://github.com/micro/go-plugins). Contributions are welcome!
-## How does it work?
-
-
- 
-
-
-Go Micro is a framework that addresses the fundamental requirements to write microservices.
-
-Let's dig into the core components.
-
-### Registry
-
-The registry provides a service discovery mechanism to resolve names to addresses. It can be backed by consul, etcd, zookeeper, dns, gossip, etc.
-Services should register using the registry on startup and deregister on shutdown. Services can optionally provide an expiry TTL and reregister
-on an interval to ensure liveness and that the service is cleaned up if it dies.
-
-### Selector
-
-The selector is a load balancing abstraction which builds on the registry. It allows services to be "filtered" using filter functions and "selected"
-using a choice of algorithms such as random, roundrobin, leastconn, etc. The selector is leveraged by the Client when making requests. The client
-will use the selector rather than the registry as it provides that built in mechanism of load balancing.
-
-### Transport
-
-The transport is the interface for synchronous request/response communication between services. It's akin to the golang net package but provides
-a higher level abstraction which allows us to switch out communication mechanisms e.g http, rabbitmq, websockets, NATS. The transport also
-supports bidirectional streaming. This is powerful for client side push to the server.
-
-### Broker
-
-The broker provides an interface to a message broker for asynchronous pub/sub communication. This is one of the fundamental requirements of an event
-driven architecture and microservices. By default we use an inbox style point to point HTTP system to minimise the number of dependencies required
-to get started. However there are many message broker implementations available in go-plugins e.g RabbitMQ, NATS, NSQ, Google Cloud Pub Sub.
-
-### Codec
-
-The codec is used for encoding and decoding messages before transporting them across the wire. This could be json, protobuf, bson, msgpack, etc.
-Where this differs from most other codecs is that we actually support the RPC format here as well. So we have JSON-RPC, PROTO-RPC, BSON-RPC, etc.
-It separates encoding from the client/server and provides a powerful method for integrating other systems such as gRPC, Vanadium, etc.
-
-### Server
-
-The server is the building block for writing a service. Here you can name your service, register request handlers, add middeware, etc. The service
-builds on the above packages to provide a unified interface for serving requests. The built in server is an RPC system. In the future there maybe
-other implementations. The server also allows you to define multiple codecs to serve different encoded messages.
-
-### Client
-
-The client provides an interface to make requests to services. Again like the server, it builds on the other packages to provide a unified interface
-for finding services by name using the registry, load balancing using the selector, making synchronous requests with the transport and asynchronous
-messaging using the broker.
-
-
-The above components are combined at the top-level of micro as a **Service**.
## Getting Started
@@ -276,6 +222,61 @@ go run client.go
Hello John
```
+## How does it work?
+
+
+
+
+
+Go Micro is a framework that addresses the fundamental requirements to write microservices.
+
+Let's dig into the core components.
+
+### Registry
+
+The registry provides a service discovery mechanism to resolve names to addresses. It can be backed by consul, etcd, zookeeper, dns, gossip, etc.
+Services should register using the registry on startup and deregister on shutdown. Services can optionally provide an expiry TTL and reregister
+on an interval to ensure liveness and that the service is cleaned up if it dies.
+
+### Selector
+
+The selector is a load balancing abstraction which builds on the registry. It allows services to be "filtered" using filter functions and "selected"
+using a choice of algorithms such as random, roundrobin, leastconn, etc. The selector is leveraged by the Client when making requests. The client
+will use the selector rather than the registry as it provides that built in mechanism of load balancing.
+
+### Transport
+
+The transport is the interface for synchronous request/response communication between services. It's akin to the golang net package but provides
+a higher level abstraction which allows us to switch out communication mechanisms e.g http, rabbitmq, websockets, NATS. The transport also
+supports bidirectional streaming. This is powerful for client side push to the server.
+
+### Broker
+
+The broker provides an interface to a message broker for asynchronous pub/sub communication. This is one of the fundamental requirements of an event
+driven architecture and microservices. By default we use an inbox style point to point HTTP system to minimise the number of dependencies required
+to get started. However there are many message broker implementations available in go-plugins e.g RabbitMQ, NATS, NSQ, Google Cloud Pub Sub.
+
+### Codec
+
+The codec is used for encoding and decoding messages before transporting them across the wire. This could be json, protobuf, bson, msgpack, etc.
+Where this differs from most other codecs is that we actually support the RPC format here as well. So we have JSON-RPC, PROTO-RPC, BSON-RPC, etc.
+It separates encoding from the client/server and provides a powerful method for integrating other systems such as gRPC, Vanadium, etc.
+
+### Server
+
+The server is the building block for writing a service. Here you can name your service, register request handlers, add middeware, etc. The service
+builds on the above packages to provide a unified interface for serving requests. The built in server is an RPC system. In the future there maybe
+other implementations. The server also allows you to define multiple codecs to serve different encoded messages.
+
+### Client
+
+The client provides an interface to make requests to services. Again like the server, it builds on the other packages to provide a unified interface
+for finding services by name using the registry, load balancing using the selector, making synchronous requests with the transport and asynchronous
+messaging using the broker.
+
+
+The above components are combined at the top-level of micro as a **Service**.
+
## Sponsors
