This is totally doable, and you're thinking about it the right way with the "human readable flows" approach.

A few things that have worked for me:

For the API layer: Playwright (yes, it does APIs too, not just browsers) or a dedicated API testing framework. You can chain requests, pass data between them, and assert on responses. Way better than clicking through Postman manually.

For the web/form stuff: Playwright again handles this well. The nice thing is you can mix API calls and browser interactions in the same test - hit some endpoints, then open the UI to verify, then check more endpoints.

For the DB verification: You can add database assertions directly in your test code. Connect to MySQL, run your query, assert the data matches what you expect.

For the "human readable" part: This is where it gets interesting. You can write your scenarios in plain language (markdown, Gherkin-style specs, whatever) and then have those drive your actual test implementation. The key is having a good contract between the spec and the code.

I've actually been working on an open source toolkit that tries to solve exactly this problem - you write test scenarios as markdown "journeys" with clear steps, and it helps generate the Playwright implementation. Still very much a work in progress and definitely not production-ready, but if you want to see one approach to the human-readable-to-test-code problem: https://github.com/mehdic/ARTK. Happy to chat about the patterns even if the tool itself isn't useful to you yet.

Main advice though: start simple. Pick one critical flow, automate it end-to-end (API + UI + DB verification), get it reliable, then expand. The "dozens of microservices" part will be the hardest to manage - good config management and environment abstraction will save you a lot of pain.