When “just one JSON” morphs into a full-blown microservice spaghetti
Description
Screenshot of a tweet from the verified account “terminally onλine eng… (@tekbog)” with the text: “it's just sending one json from one service to another how hard can it be?”. Below the tweet is a photo of a whiteboard packed with a chaotic architecture sketch. Boxes, circles, clouds and gravestone icons are connected by arrows in every direction, labelled with whimsical service names like “CLOGGER”, “BINGO”, “SQUIRT”, “LMAIDP”, “RACCOON”, “OMEGA STAR”, “EKS”, “APP PLATFORM (MICROSERV)”, “SIMPLEX AGGREGATOR”, “HELL ROOM”, “OLYMPUS”, “Papaya”, and a cylinder marked “BREAD REPLICA”. A blurred developer stands to the right, dwarfed by the diagram’s tangle of dependencies. The visual gag highlights how a supposedly simple JSON hand-off balloons into an over-engineered, cloud-native, multi-service labyrinth - something every senior engineer has seen evolve out of scope
Comments
24Comment deleted
Somewhere between “curl -d” and prod we accidentally invented our own Kafka-on-REST-on-Lambda-on-EKS legacy
Somewhere in that diagram is a Kafka cluster that nobody remembers why we added, three different retry mechanisms because 'the first two didn't handle edge cases,' and a service called RACCOON that was supposed to be temporary but now handles 40% of production traffic and nobody dares to touch it
Ah yes, the classic 'just send JSON between services' - the distributed systems equivalent of 'just draw the rest of the owl.' What starts as a simple HTTP POST somehow metastasizes into a Kafka cluster, three message queues, a service mesh, read replicas, and a whiteboard that looks like a conspiracy theorist's cork board. By the time you've added circuit breakers, retry logic, schema validation, distributed tracing, and figured out why service LMNOP occasionally returns 418 I'm a Teapot, you've essentially recreated the entire OSI model but with more YAML. The real kicker? That 'simple JSON' now has 47 different versions across your services because nobody wanted to coordinate a breaking change during Q4
In enterprise speak, 'just send JSON' translates to provisioning EKS, wiring a mesh, adding authn/z, a schema registry, idempotency keys, retries with jitter, circuit breakers, trace propagation, DLQs - and a runbook
One JSON transfer? Sure - after it barters with Gary, dodges the MQ raccoon, and petitions EKS for a mercy port-forward
“Just send a JSON” is how you accidentally invent an ESB, a schema registry, idempotent retries with backoff, distributed tracing, and three Kubernetes namespaces - right before the PR title becomes “Initial migration.”
It can be even more fun: - green deployment - autoscaling - cross-regional resources (such as database replicas) - proper authorization with all claims/features - idempotent retries on failure - logs, metrics, and monitoring - infrastructure as code Want it harder? Ensure the protection of PII and compliance with all relevant policies. After 3-6 months of development, you'll finally be able to "send one json from one service to another." P. S.: I'm sure I forgot something in the list. Bring your pain, please. Comment deleted
- proper permissions, connectivity with load balancers and their configuration within the cloud (though using cloud shit itself instead of good ol' vps/bare metal is a pain itself) Comment deleted
Oh, ofc resources permissions and rates (say "hello" to cross-regional again). LB is a part of K8s nowadays, if you don't mean DR. And how could I have forgotten about disaster recovery... Comment deleted
Here are some more from gpt - Thorough Testing: Unit, integration, e2e, and load tests because the mantra "it works on my machine" doesn't quite cut it in professional settings. - Multiple Environments: Development, staging, QA – each meticulously crafted to never quite replicate the production environment. - Secrets Management: Where passwords and API keys go to avoid becoming public domain. Better safe than sorry. - Developer Experience (DX): Enhance the developer workflow with tools and documentation, turning the ordeal into something bearably productive. - Automated Rollbacks: Implement failsafes to gracefully revert changes post-deployment, because sometimes the best way to move forward is to take a step back. - API Rate Limiting: Incorporate sensible rate limits to protect your services from being overwhelmed. - Data Encryption & Privacy: Encrypt data in transit and at rest, honoring user privacy and regulatory mandates, because trust is your application's foundation. - Error Handling & Graceful Degradation: Design your system to fail gracefully, ensuring that even when things go south, the user experience doesn't plummet with it. - Automated Canary Releases: Gradually roll out changes to a small subset of users, because testing in production is the new extreme sport, but it's better with a safety net. Comment deleted
Sure thing, unit tests and integration tests are must-haves. Dev/QA/Canary environments too. Vaults are somewhat optional, but if we are talking about two different services, some kind of common configuration (e.g., auth key) should be stored in a secret vault. Privacy is already included in PII and related policies. Comment deleted
Nobody told about that shit first time that i saw json :c Comment deleted
Haha, json, just move strings, sounds like a great fun Comment deleted
Eww json, protobufs are the way to go. Comment deleted
Ew protobuf, just gzip raw text Comment deleted
The problem with any text format is that you have to parse it. Even if you have a library to parse it for you, it still has to be parsed. Which is kinda dumb. Comment deleted
Protobuf also needs to be parsed 🤔 Comment deleted
How so? Comment deleted
Typo. But protobuf generally requires using some sort of library which is still parsing it under the hood. Comment deleted
It's just raw data, the library is effectively just providing type data and pointer offsets. Not actually parsing the data. The data is already in the desired format. You dont have to convert from string to int, it's just already an int. Comment deleted
protobuf has varints, it's literally not "already an int"... Comment deleted
Everything's binary at some point Comment deleted
So?.. Comment deleted
It's a joke :) Comment deleted