A few things to consider in your architecture:
separate the entry point in the system from my service
It depends if you want to expose capabilities of your services and create api gateway or you just want to replace direct communication with messages, increasing availability and decrease latency of your system. Think twice if you will need some data/business logic before creating the message published to Kafka.
easily allow scale up of the solution
Although event-driven approach may increase your throughput it is not increasing capability of your system to scale up. Splitting wisely your services and creating stateless system do. E.g. consider, in your solution, how easy it will be to read messages from Kafka from many nodes. This may help you to realize if you can easily scale or not your entire solution. Your system is most likely not only about gathering request but also about processing.
allow service to go offline for maintenance/upgrade
It also depends. Your business case can either allow it or not. You will need to properly handle different scenarios, especially when some operation fails. You will also need to handle messages queued while your workers stop reading messages. There are simpler solutions to meet requirement of no downtime maintenance/upgrade than that one.
To sum up, you need to think about the details and probably consider lower level of abstraction to see potential difficulties.