Everyone has a creative spark in them. Some bring their ideas to life with digital tools, others capture the perfect moment with a camera or love to grab pen and paper to create little doodles or pieces of lettering. And even if you don’t think of yourself as particularly creative, who knows? There might be a hidden talent waiting to be discovered!

That’s exactly what our monthly wallpapers series has been all about for over 15 years now. It’s a chance to step away from the everyday and dive into a fun, creative project. And this month is no different!

Talented artists and designers from all over the world have once again put their skills to work, creating unique and inspiring desktop wallpapers to brighten up your screens this June. You’ll find their designs below, along with some favorites from our archives that were just too good to leave out. A huge thank you to everyone who shared their creations with us this month — you’re smashing!

If you too would like to get featured in one of our upcoming wallpapers posts, please don’t hesitate to join in. We can’t wait to see what you’ll come up with! Happy June!

• You can click on every image to see a larger preview.
• We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.

Drifting Into June

“June marks the beginning of summer and the end of the semester for many colleges. When I think of summer, I think of walks along the park with my family watching ducks swimming in the lake, and swimming in our pool with my siblings. Naturally from there I put them together to create an amusing scene of a duck slowly paddling around in an inner tube.” — Designed by Emma Kim from the United States.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Let The Ocean Influence You

“The ocean covers more than 70% of the surface of the Earth, yet we know barely anything about it. Maybe June can be the month you discover something new about yourself.” — Designed by Ginger IT Solutions from Serbia.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Dancing In The Kitchen

“June is such an iconic summer month, filled with sunshine, hope, and possibilities. When we raise both hands above our heads in celebratory dance, we symbolically release our cares for the day. When we do this dance in the kitchen, we not only release but also celebrate our bodies, our souls, and nourishment we’re about to give ourselves. This digital collage represents the freedom of movement, of dance, of joyful expression, of nourishment, creativity, and hope. May we all dance in the kitchen.” — Designed by Sue Jenkins from the United States.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Fruit & Gingham

“June reminds me of fresh fruit and bright colors, so I decided to watercolor some fruits, and it complimented well on a blue gingham picnic table background!” — Designed by Ella Peplowski from Ringwood, NJ.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Not In The Mood Forecast

Designed by Ricardo Gimenes from Spain.

• preview
• with calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Ballpark Patches

“June brings in warmer weather, so I designed a baseball-patch-inspired piece to celebrate the start of the season and the nice weather.” — Designed by Madison Evans from Scranton, PA.

• preview
• with calendar: 320×480, 640×480, 800×480, 1024×768, 1280×720, 1280×800, 1280×960, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 1024×768, 1280×720, 1280×800, 1280×960, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

A Very Special Amusement Park

“June brings summer, and it’s a great time to travel and experience new adventures! An amusement park is always a good idea, although some are best enjoyed from the comfort of your own home.” — Designed by Veronica Valenzuela from Spain.

• preview
• with calendar: 640×480, 800×480, 1024×768, 1280×720, 1280×800, 1440×900, 1600×1200, 1920×1080, 1920×1440, 2560×1440
• without calendar: 640×480, 800×480, 1024×768, 1280×720, 1280×800, 1440×900, 1600×1200, 1920×1080, 1920×1440, 2560×1440

Wavy Jellyfish

Designed by Jayden Evans from Scranton, Pennsylvania.

• preview
• with calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Buzzing Through June

“I first found this color palette and thought it was very springy, and when I think of spring I think of flowers and bees. So I wanted to create a design that incorporated both in a cute way.” — Designed by Caroline Flynn from the United States.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Tiny Paradise Under the Sun

“Summer is hidden in the simple moments — the shimmer of crystal water, the warmth of the sun on your skin, and the calm sound of a peaceful afternoon. The warm wooden deck and soft shade of the parasol create a peaceful corner made for daydreaming. Flowers bloom, lemonade stays cold, and the sunlight dances across the pool like a golden melody. It’s the season of relaxation, happiness, and small moments that feel unforgettable.” — Designed by PopArt Studio from Novi Sad, Serbia.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Patches Of Flowers

“I wanted to make something in Blender, and once I made these flowers I felt like it needed something more, so I added more texture and more colors to make these flowers more peaceful.” — Designed by Caroline Flynn from the United States.

• preview
• with calendar: 320×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440
• without calendar: 320×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440

Amsterdam

“Inspired by the upcoming 2027 edition of SmashingConf Amsterdam.” — Designed by Ricardo Gimenes from Spain.

• preview
• with calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Let Me Grow With You

Designed by James Lucia from Covington Township, Pennsylvania.

• preview
• with calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Travel Time

“June is our favorite time of the year because the keenly anticipated sunny weather inspires us to travel. Stuck at the airport, waiting for our flight but still excited about wayfaring, we often start dreaming about the new places we are going to visit. Where will you travel to this summer? Wherever you go, we wish you a pleasant journey!” — Designed by PopArt Studio from Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

June Is For Nature

“In this illustration, Earth is planting a little tree — taking care, smiling, doing its part. It’s a reminder that even small acts make a difference. Since World Environment Day falls in June, there’s no better time to give back to the planet.” — Designed by Ginger IT Solutions from Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1020, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Tastes Of June

“A vibrant June wallpaper featuring strawberries and fresh oranges, capturing the essence of early summer with bright colors and seasonal charm.” — Designed by Libra Fire from Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

A Bibliophile’s Shelf

“Some of my favorite things to do are reading and listening to music. I know that there are a lot of people that also enjoy these hobbies, so I thought it would be a perfect thing to represent in my wallpaper.” — Designed by Cecelia Otis from the United States.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1200, 1920×1440, 2560×1440

Here Comes The Sun

Designed by Ricardo Gimenes from Spain.

• preview
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Create Your Own Path

“Nice weather has arrived! Clean the dust off your bike and explore your hometown from a different angle! Invite a friend or loved one and share the joy of cycling. Whether you decide to go for a city ride or a ride in nature, the time spent on a bicycle will make you feel free and happy. So don’t wait, take your bike and call your loved one because happiness is greater only when it is shared. Happy World Bike Day!” — Designed by PopArt Studio from Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Deep Dive

“Summer rains, sunny days, and a whole month to enjoy. Dive deep inside your passions and let them guide you.” — Designed by Ana Masnikosa from Belgrade, Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Oh, The Places You Will Go!

“In celebration of high school and college graduates ready to make their way in the world!” — Designed by Bri Loesch from the United States.

• preview
• without calendar: 320×480, 1024×768, 1280×1024, 1440×900, 1680×1050, 1680×1200, 1920×1440, 2560×1440

Merry-Go-Round

Designed by Xenia Latii from Germany.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Join The Wave

“The month of warmth and nice weather is finally here. We found inspiration in the World Oceans Day which occurs on June 8th and celebrates the wave of change worldwide. Join the wave and dive in!” — Designed by PopArt Studio from Serbia.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Summer Surf

“Summer vibes…” — Designed by Antun Hirsman from Croatia.

• preview
• without calendar: 640×480, 1152×864, 1280×1024, 1440×900, 1680×1050, 1920×1080, 1920×1440, 2650×1440

Summer Party

Designed by Ricardo Gimenes from Spain.

• preview
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Expand Your Horizons

“It’s summer! Go out, explore, expand your horizons!” — Designed by Dorvan Davoudi from Canada.

• preview
• without calendar: 800×480, 800×600, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Handmade Pony Gone Wild

“This piece was inspired by the My Little Pony cartoon series. Because those ponies irritated me so much as a kid, I always wanted to create a bad-ass pony.” — Designed by Zaheed Manuel from South Africa.

• preview
• without calendar: 800×600, 1024×768, 1280×960, 1280×1024, 1680×1050, 1920×1200, 2560×1440, 2880×1800

Pineapple Summer Pop

“I love creating fun and feminine illustrations and designs. I was inspired by juicy tropical pineapples to celebrate the start of summer.” — Designed by Brooke Glaser from Honolulu, Hawaii.

• preview
• without calendar: 640×480, 800×600, 1024×768, 1152×720, 1280×720, 1280×800, 1280×960, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200, 1920×1440, 2560×1440

All-Seeing Eye

Designed by Ricardo Gimenes from Spain.

• preview
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440, 3840×2160

Nine Lives

“I grew up with cats around (and drawing them all the time). They are so funny… one moment they are being funny, the next they are reserved. If you have place in your life for a pet, adopt one today!” — Designed by Karen Frolo from the United States.

• preview
• without calendar: 1024×768, 1024×1024, 1280×800, 1280×960, 1280×1024, 1366×768, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Summer Coziness

“I’ve waited for this summer more than I waited for any other summer since I was a kid. I dream of watermelon, strawberries, and lots of colors.” — Designed by Kate Jameson from the United States.

• preview
• without calendar: 320×480, 1024×1024, 1280×720, 1680×1200, 1920×1080, 2560×1440

Bauhaus

“I created a screenprint of one of the most famous buildings from the Bauhaus architect Mies van der Rohe for you. So, enjoy the Barcelona Pavillon for your June wallpaper.” — Designed by Anne Korfmacher from Germany.

• preview
• without calendar: 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Strawberry Fields

Designed by Nathalie Ouederni from France.

• preview
• without calendar: 320×480, 1024×768, 1280×1024, 1440×900, 1680×1200, 1920×1200, 2560×1440

Papa Merman

“Dream away for a little while to a land where June never ends. Imagine the ocean, feel the joy of a happy and carefree life with a scent of shrimps and a sound of waves all year round. Welcome to the world of Papa Merman!” — Designed by GraphicMama from Bulgaria.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Solstice Sunset

“June 21 marks the longest day of the year for the Northern Hemisphere — and sunsets like these will be getting earlier and earlier after that!” — Designed by James Mitchell from the United Kingdom.

• preview
• without calendar: 1280×720, 1280×800, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200, 2560×1440, 2880×1800

Getting Better Everyday

“Inspired by the eternal forward motion to get better and excel.” — Designed by Zachary Johnson-Medland from the United States.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1366×768, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Reef Days

“June brings the start of summer full of bright colors, happy memories, and traveling. What better way to portray the goodness of summer than through an ocean folk art themed wallpaper. This statement wallpaper gives me feelings of summer and I hope to share that same feeling with others.” — Designed by Taylor Davidson from Kentucky.

• preview
• without calendar: 480×800, 1024×1024, 1242×2208, 1280×1024

Ice Creams Away!

“Summer is taking off with some magical ice cream hot air balloons.” — Designed by Sasha Endoh from Canada.

• preview
• without calendar: 320×480, 1024×768, 1152×864, 1280×800, 1280×960, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1920×1080, 1920×1200, 2560×1440

Melting Away

Designed by Ricardo Gimenes from Spain.

• preview
• without calendar: 320×480, 640×480, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1366×768, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Sunset With Crabs

“In the sunset, the crabs come to the surface. That little boat can’t sail, but after seeing the crabs it gets power and finally… it sails!” – Designed by Veronica Valenzuela from Spain.

• preview
• without calendar: 640×480, 800×480, 1024×768, 1280×720, 1280×800, 1440×900, 1600×1200, 1920×1080, 1920×1440, 2560×1440

World Environment Day

“On June 5th, we celebrate World Environment Day — a moment to pause and reflect on how we impact Earth’s health. A few activities represented in this visual include conserving energy and water, shopping and growing local, planting flowers and trees, and building a sustainable infrastructure.” — Designed by Mad Fish Digital from Portland, OR.

• preview
• without calendar: 320×480, 1024×1024, 1280×720, 1680×1200, 1920×1080, 2560×1440

Shine Your Light

“Shine your light, Before the fight, Just like the sun, Cause we don’t have to run.” — Designed by Anh Nguyet Tran from Vietnam.

• preview
• without calendar: 768×1280, 1024×1024, 1280×800, 1280×1024, 1366×768, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Get Featured Next Month

Feeling inspired? We’ll publish the July wallpapers on June 30, so if you’d like to be part of the collection, please don’t hesitate to submit your design. We are already looking forward to it!

TL;DR (Quick Answer)

This is an honest engineering write-up of a MOGONET-style multi-omics consensus biomarker pipeline built as an internal R&D project at sysofti.

• The headline — on a small synthetic cohort (n=30), the graph network alone scores near-random in leak-free 5-fold cross-validation (AUC 0.53 ± 0.16). Yet as one voter in a 5-evidence consensus, the top-10 ranking is 90% real markers (9 of 10 are known periodontitis genes).
• The lesson — a single model that looks weak in honest evaluation can still be a useful voter. That contrast is the whole point of the consensus design, and we show it with data.
• What it is — per-omics Graph Convolutional Networks (GCN) over a sample-similarity graph, attention-fused, contributing to a consensus score alongside differential-expression hubs, Random Forest, a DNN, and co-expression modules.
• What it is *not* — the official MOGONET. We dropped the original’s VCDN fusion for attention fusion. Call it “MOGONET-based.” All numbers are from synthetic data with embedded ground-truth markers — code validation, not a clinical claim.

If you’re implementing multi-omics integration, the parts you can’t get from the paper are below: the real results, the leakage-aware evaluation, and the bugs we hit.

What MOGONET Is (the One-Line Mental Model)

MOGONET (Multi-Omics Graph cOnvolutional NETwork) learns a separate GCN per omics view on a sample-similarity graph (patients as nodes, edges by feature similarity), then fuses the per-view embeddings for classification and biomarker discovery. Reference: Wang et al. 2021, Nature Communications 12:3445; the GCN itself is Kipf & Welling 2017.

Mental model: “build one graph net per omics layer, let each form an opinion, then combine those opinions.”

What We Simplified — and Why

The original MOGONET fuses views with a View Correlation Discovery Network (VCDN). We replaced it with attention-weighted fusion:

• Why — with tiny cohorts (tens of samples), VCDN’s extra parameters were a liability; attention fusion gave a simpler intermediate-fusion scheme that still up-weights the more informative omics per sample.
• The tradeoff — we lose the explicit cross-view correlation modeling that is part of MOGONET’s original contribution. So this is honestly MOGONET-based, not a reimplementation. The source docstring says as much: “Simplified implementation of MOGONET.”

Architecture

Input: X_views = [omics1 (n×p1), omics2 (n×p2), ...]   (n = common samples)
  └─ per-view StandardScaler
  └─ per-view k-NN (cosine) adjacency  (n×n)
ViewEncoder (per omics):  GraphConv(p→128) → BN → ReLU → GraphConv(128→64)
  → view embedding (n×64)
Attention fusion:  softmax(Linear(64→1)) over views → weighted sum (n×64)
Classifier:  Linear(64→32) → ReLU → Linear(32→n_classes)

class GraphConvLayer(nn.Module):
    def __init__(self, in_features, out_features):
        super().__init__()
        self.linear = nn.Linear(in_features, out_features)
    def forward(self, x, adj):
        return torch.mm(adj, self.linear(x))   # propagate over the sample graph

class MOGONET(nn.Module):
    def __init__(self, input_dims, hidden_dim=128, latent_dim=64, n_classes=2):
        super().__init__()
        self.encoders = nn.ModuleList([ViewEncoder(d, hidden_dim, latent_dim) for d in input_dims])
        self.attention = nn.Linear(latent_dim, 1)
        self.classifier = nn.Sequential(nn.Linear(latent_dim, 32), nn.ReLU(), nn.Linear(32, n_classes))
    def forward(self, views, adjs):
        embeddings = [enc(x, adj) for enc, x, adj in zip(self.encoders, views, adjs)]
        stacked = torch.stack(embeddings, dim=0)                       # n_views × n × latent
        attn = F.softmax(self.attention(stacked).squeeze(-1), dim=0)   # per-view, per-sample
        fused = (stacked * attn.unsqueeze(-1)).sum(dim=0)              # n × latent
        return self.classifier(fused)

Sample-similarity graph — k-NN (cosine), no self-loops on purpose (see below):

def build_adjacency(X, k=5):
    sim = cosine_similarity(X)
    adj = np.zeros_like(sim)
    for i in range(len(sim)):
        top_k = np.argsort(sim[i])[-k-1:-1]      # top-k neighbours, excluding self
        adj[i, top_k] = sim[i, top_k]
        adj[top_k, i] = sim[top_k, i]            # symmetrize
    row_sum = adj.sum(axis=1, keepdims=True); row_sum[row_sum == 0] = 1   # guard zero-sum rows
    return adj / row_sum

The Engineering Decisions That Mattered

• Sample-node graph, not feature graph. Nodes are patients; edges are patient-patient similarity. Same-group patients cluster, so the GCN smooths group signal.
• No self-loops — on purpose. Standard GCN uses Ahat = A + I so a node keeps its own features. We deliberately omit the self-loop so each node’s representation is built purely from its sample-neighborhood, pushing the model toward group structure rather than individual raw features. It is a tradeoff (you give up the node’s own signal each layer), and we flag it as a choice, not an accident.
• Per-view scaling + common-sample intersection. Each omics standardized independently; only samples present in all views are used.
• Consensus over a single model. MOGONET is one of five evidence sources by design — Hub (DE+PPI), ML (Random Forest), DL (DNN), WGCNA co-expression, and MOGONET — with a multi-evidence bonus:

avg_score = sum(scores.values()) / max(len(scores), 1)
composite = avg_score * (1 + 0.3 * (n_sources - 1))   # reward agreement across sources

As the results show, this design choice is what makes the pipeline useful despite any single model being weak.

Results (Synthetic Data, with Ground Truth)

We validate on a synthetic periodontitis case-control set (3 omics — transcriptomics 500, proteomics 200, metabolomics 100 features × 30 samples, 15 disease / 15 control, seed-fixed) with known biomarkers deliberately embedded: up-regulated inflammatory genes (MMP8, MMP9, IL1B, IL6, TNF, RANKL, CTSK, TLR4 …) and down-regulated bone-formation genes (COL1A1, RUNX2, SP7, BGLAP, OPG …). Embedding known markers gives ground truth — you can check whether the pipeline recovers them, which is impossible on a real cohort.

Note on sources: the pipeline defines five evidence sources, but in this run WGCNA returned no co-expression hubs, so four sources actually contributed (Hub, ML, DL, MOGONET).

The consensus ranking surfaces real markers

Of 793 candidate features, the top-30 consensus included 13 of the 25 embedded markers. The ranking is strikingly clean at the top:

• Precision@10 = 0.90 — 9 of the top 10 are known markers (only METAB_0031 is not).
• Recall@10 = 0.36, Recall@20 = 0.52 (9 then 13 of 25 known markers); it plateaus by 20 because a few embedded markers were given weak synthetic signal (e.g. TNF, fold-change ≈ 1.1).

More evidence = more trustworthy

Breaking the top-30 down by which sources agreed makes the consensus logic concrete:

• 4 sources → 3 genes, all 3 known (100%): MMP8, MMP9, IL1B.
• 3 sources → 17 genes, 9 known.
• 2 sources (DL + MOGONET) → 8 genes, 0 known — pure noise.
• 1 source → 2 genes, 1 known.

The signal lives where independent methods agree. A gene flagged by four sources was always real here; genes flagged by only two were not.

The honest part: the graph net alone is near-random

We cross-validated MOGONET as a standalone classifier, rebuilding the sample graph from training folds only to avoid leakage:

MOGONET 5-fold CV AUC = 0.53 ± 0.16 (folds: 0.44, 0.44, 0.78, 0.33, 0.67)

That is barely above chance. With n=30 (six test samples per fold) and a transductive sample-graph model, a single GCN simply cannot generalize here — and its training AUC near 1.0 is mostly the leakage and the injected signal talking. This is exactly why MOGONET is wired in as one voter, not the decision-maker. The consensus result above is strong because it doesn’t trust any single model, including this one.

Honest Limitations

1. Simplified model. No VCDN fusion — attention instead. “MOGONET-based,” not a reimplementation.
2. MOGONET is a weak standalone classifier here (CV AUC 0.53). Useful only in aggregate. It also scores all 793 features, so its solo discriminative power is low.
3. Synthetic, small (n=30). Results validate the code’s ability to recover injected signal — not clinical performance. External cohorts are required for any real claim.
4. Single run (seed 42). Known markers are stable at the top; the unnamed GENE_xxxx candidates shuffle on re-runs.
5. Self-loop omission is a design choice with a cost — worth A/B testing against the standard A + I formulation.
6. Feature importance is an approximation (first-layer weight magnitude), not a gradient-based attribution.

What Broke Along the Way (Real Notes)

• Zero-sum adjacency → NaN. If a sample’s k-NN cosine similarities summed to zero, row-normalization divided by zero and propagated NaNs. Fixed with a row_sum[row_sum == 0] = 1 guard.
• Attribute-name mismatches (fixed twice). Pulling feature importance broke on AttributeError when the sklearn-wrapper conventions clashed with the nn.Module attribute names (view_encoders → encoders, model → model_).
• Common-sample collapse. When omics measured different sample sets, the intersection shrank fast. Added a “≥6 common samples” guard that skips gracefully instead of crashing.
• MOGONET scores everything. It assigns weight to all 793 features, so it appeared in all top-30 entries — the multi-evidence bonus is what keeps it honest.

What We’d Improve Next

• Report consensus performance under the same leak-free CV, not just MOGONET’s.
• A/B test self-loops (Ahat = A + I).
• Gradient-based attribution (Integrated Gradients) instead of first-layer weights.
• Add VCDN fusion and compare head-to-head with attention fusion.
• External multi-omics cohort for real-world validation.

FAQ

Q: Is this the official MOGONET implementation?

No — a simplified, MOGONET-based design: per-omics GCN with attention fusion, without the original’s VCDN view-correlation network.

Q: If MOGONET’s CV AUC is only 0.53, why keep it?

Because it is one voter in a five-source consensus, not the classifier. Single models overfit small cohorts; consensus rewards agreement across independent methods, and that ranking recovered known markers at 90% precision in the top 10. A weak voter still adds signal when combined.

Q: Why validate on synthetic data?

Embedded known markers give ground truth, so you can measure recovery (recall/precision) — impossible on a real cohort where the answer is unknown. It validates the code, not clinical utility.

Q: Why omit GCN self-loops?

Intentional: without a self-loop, each node’s representation comes purely from its sample-neighborhood, pushing the model toward group structure rather than individual features. It is a tradeoff worth A/B testing, not a universal recommendation.

Q: Can I use this on my own multi-omics data?

Yes — the classifier is sklearn-compatible (fit/predict/predict_proba). Build the sample graph from training data only to avoid leakage, and don’t over-read AUC on small cohorts.

Resources

• Reference implementation (clean, standalone, MIT): github.com/shoo99/mogonet_lite
• Original paper: Wang T. et al. (2021), MOGONET integrates multi-omics data via graph convolutional networks for biomarker discovery, Nat Commun 12:3445.

Every engineering team runs into the same annoying problem sooner or later. Monitoring tells you that something is broken, but it usually stops right there. You can see error rates. You can see latency spikes. You can see failed requests. But the questions that matter during an incident are often still unanswered.

Who owns this service? What depends on it? Where is the runbook? Which Slack channel should I use? Is this a real outage or a known failure mode?

That gap is exactly why I put together this small Agentic Observability demo. I built a tiny shopping app, instrumented it with OpenTelemetry, sent the telemetry into Dynatrace, and then used Port as the context layer so I could connect operational signals with engineering knowledge. The result is a much more useful troubleshooting workflow. Instead of staring at dashboards and guessing, I can ask what is happening and get back both live health data and human context in one place.

This setup is intentionally small, but it maps really well to the kind of confusion that happens in real systems. The app has products, a cart, checkout flow, and a few baked-in failure scenarios so the observability story actually has something interesting to surface.

The real problem with observability today

Traditional observability is good at detection. It can tell me that a service is unhealthy, response times are increasing, or failures are climbing. That is valuable, of course. But during incident response, detection is only the starting point.

The painful part begins immediately after that.

• I need to know which team owns the service.
• I need to know the service tier and whether it is business critical.
• I need to understand upstream and downstream dependencies.
• I need the right runbook.
• I need to know how to contact the people who can fix it.
• I need enough context to understand whether the anomaly is expected, accidental, or part of a test.

This is where Agentic Observability becomes interesting. The goal is not just to collect telemetry. The goal is to make the telemetry actionable by connecting it to the operational and organizational context around the system.

The demo architecture at a glance

I kept the demo simple on purpose. There are only three major pieces involved, but together they create a much stronger workflow than any single tool would provide alone.

A Flask shopping app that simulates realistic user behavior and failures.
Dynatrace to ingest traces and analyze service health, latency, logs, and errors.
Port as the context layer, storing service ownership, tier, runbooks, Slack channels, and related metadata.

The connection point between the observability platform and the context layer is the MCP connector in Port. I used that to connect the Dynatrace MCP server, which lets Port access live monitoring data while still grounding the experience in engineering context.

That combination is really the whole idea behind this version of Agentic Observability. Dynatrace knows what is happening technically. Port knows what that service means inside the organization.

What I built: a tiny Flask e-commerce app

The application itself is intentionally modest. It is a small e-commerce style service with a few common user actions:

• Browsing products
• Adding items to the cart
• Checking out
• Viewing orders

It is not meant to be production-grade commerce software. It is just realistic enough to behave like a real service and produce interesting telemetry.

I also added fake traffic and fake failures into the flow. That mattered because I did not want a perfect demo where everything stays green all the time. Real systems fail in messy ways, and a good Agentic Observability setup should help make sense of that mess.

Some checkout flows succeed. Some fail. Some traffic is generated artificially. The point is to create enough activity that the tools have something meaningful to detect and explain.

Step 1: Auto-instrument the app with OpenTelemetry

The first layer is instrumentation. I wrapped the Flask app with OpenTelemetry so requests automatically emit traces. I did not need to write a bunch of custom tracing logic for every endpoint. That keeps the setup cleaner and closer to how I would want to instrument a real service quickly.

Once that was in place, every request moving through the shop could generate telemetry data, including:

• Request traces
• Errors
• Latency information
• Operational signals around the application flow

This is the foundation. Without it, there is no visibility into what the app is actually doing.

Step 2: Stream traces into Dynatrace

After instrumentation, the traces stream directly into Dynatrace. Dynatrace auto-detects the service and begins tracking the health of the application in real time.

For this demo, that meant I could quickly see:

• The service showing up as an active monitored workload
• Traffic spikes from the generated activity
• Error behavior during intentional checkout failures
• Latency and service-level patterns over time

This part is classic observability. Dynatrace is doing exactly what an observability platform should do: gather the signals, analyze them, and make abnormal behavior visible.

But again, raw visibility is not the whole story.

Step 3: Add the missing context in Port

This is where things get a lot more useful.

I modeled the service in Port. Port acts as an agentic developer platform and, in this setup, it works as a context layer over the telemetry coming from Dynatrace. That context includes the kind of information engineers usually have to hunt down manually during an incident.

For the service, I stored details like:

• Owner of the service
• Tier or criticality level
• Environment
• Runbook
• Slack channel for communication
• Dependencies related to the service

This is the missing half of incident response. When a metric turns red, I do not want to begin a scavenger hunt. I want the operational signal and the human context tied together.

How the Dynatrace MCP server fits into the workflow

The Port MCP connector is what ties everything together. I used it to connect the Dynatrace MCP server into Port, which means Port can reach into Dynatrace when needed and pull live monitoring data as part of a contextual query.

That matters because now I am not bouncing between disconnected tools mentally. Instead, Port can combine:

• Its own service metadata
• Ownership and operational details
• Live health information from Dynatrace
• Relevant answers returned through agentic queries

Port supports multiple data source patterns, including APIs, GitOps, infrastructure-as-code, web integrations, and MCP servers. For this demo, the Dynatrace MCP integration was the key piece because it let me bridge observability data and service context directly.

Running the app and generating failures

Once the shop app was running locally, I exercised the common paths: browse products, add them to the cart, and go through checkout. I also generated some fake user activity and deliberately introduced failures during checkout.

That created the exact kind of mixed operational picture I wanted:

• Normal requests
• Confirmed orders
• Periodic failures
• Traffic increases over time

In the orders view, I could see the system state changing as synthetic traffic and failures were happening. In Dynatrace, the service activity became visible as spikes and behavioral changes. That gave me enough signal to test whether the full Agentic Observability flow could actually explain what was going on.

What the agentic query experience looks like

After connecting Dynatrace and Port, I could ask a plain-language question about the service rather than manually piecing everything together from dashboards and documents.

I queried the system about what was happening with the demo service. Port AI, which is the native chat experience inside Port, then began collecting data from both Port and Dynatrace in parallel.

That is an important detail. It was not just answering from one static metadata record. It was combining two different kinds of information:

Entity context from Port, such as owner, tier, environment, runbook, and communication channel
Health metrics from Dynatrace, such as traffic, recent behavior, and failures

That is the essence of Agentic Observability. The system is not merely showing a chart. It is assembling the context needed to reason about the chart.

The answer gets a lot more useful than a red metric

Once the query completed, I got back a consolidated view of the service.
It identified the service and surfaced key metadata such as:

• The owning team
• The service tier
• The environment
• The communication channel
• The runbook location
• Whether there were any open incidents
• Recent traffic behavior over the last couple of hours

That is already a huge improvement over standard monitoring alone. Instead of only knowing that a service is active or unhealthy, I immediately know how that service fits into the engineering organization.

Then I asked a deeper follow-up question about the cause of failures.

The system checked the logs and correlated what it found. The result was actually reassuring: the error was not some mysterious production bug. It was an intentionally hardcoded failure in the demo, resulting in a 500 internal server error during checkout.

That answer is exactly what I wanted to prove. With a good Agentic Observability flow, I should be able to distinguish quickly between:

• A real incident
• A synthetic test
• A known intentional failure mode
• An unexpected regression

Why this pattern matters for engineering teams

The demo is small, but the bottleneck it addresses is very real.

In many teams, observability data lives in one place, service ownership in another, runbooks in another, incident tools somewhere else, and tribal knowledge in Slack or people’s heads. During an outage, every extra click and every missing piece of context adds delay.

This approach reduces that friction by bringing the pieces together.

Agentic Observability is useful because it helps answer the operational questions that come right after detection:

• What failed?
• Why is it failing?
• Who owns it?
• What should happen next?
• Where is the documentation?
• Is this service connected to other important systems?

Instead of forcing an engineer to manually join that information, the platform can do it for them.

What Port contributes beyond simple metadata

It is easy to think of Port as just a catalog for services, but in this setup it does something more important. It serves as a reliable operational context layer for engineering teams.

Because the service entity in Port includes ownership, deployment-related knowledge, team details, and related service information, Port becomes the right place to anchor agentic queries. Dynatrace provides the live signal. Port provides the meaning around the signal.

That is why the answers become much more actionable. The system is not simply observing. It is interpreting the observation in the context of how the organization actually works.

You can extend the same pattern to other tools

Although this demo used Dynatrace, the broader pattern is not limited to one observability vendor. Port’s MCP connector approach makes it possible to connect multiple developer tools and bring them into the same context-rich workflow.

I specifically called out that the same idea can be extended to tools like:

• PagerDuty
• New Relic
• Other MCP-enabled developer and operations tools

So the bigger idea here is not “use one tool for everything.” The bigger idea is “build a context layer that can speak to the right tools and answer engineering questions with the full picture.”

The data flow behind this Agentic Observability demo

The end-to-end flow for the demo is straightforward:

• A shopper interacts with the Flask application.
• OpenTelemetry captures traces as requests move through the system.
• Dynatrace ingests and analyzes those traces, logs, and errors.
• The Dynatrace MCP server is connected into Port.
• Port combines live monitoring data with service context.
• Agentic queries return an operationally meaningful answer instead of isolated raw metrics.

That pipeline is the practical core of Agentic Observability. Instrument the app, collect the signals, connect the tools, add the missing human context, and let engineers query the system in a way that reflects how incidents actually happen.

What I liked most about this setup

The most useful part was not the dashboard itself. It was the reduction in ambiguity.

When something breaks, I do not want five tabs open and three separate searches just to figure out basic ownership and intent.
I want one place that can tell me:

• What changed
• What is unhealthy
• Whether the failure is real or expected
• Who needs to be involved
• What the next step should be

That is why this style of Agentic Observability feels promising. It closes the gap between telemetry and action.

Final thoughts

This demo was intentionally small, but the lesson is not small at all. Good observability should do more than report failures. It should help engineering teams respond with confidence.

Dynatrace handled the telemetry side beautifully. Port added the context that observability platforms often do not have on their own. Connecting the two through the MCP layer created a workflow where I could ask what is happening with a service and get back something genuinely useful.

That, to me, is the practical value of Agentic Observability. It is not just about smarter dashboards or nicer charts. It is about turning system signals into answers that are grounded in ownership, dependencies, documentation, and action.

If you are trying to make incident response less chaotic, this pattern is absolutely worth exploring.

I remember a deal I lost in 2018 — a $2M automation project in Guangzhou. I had the best product, the best price, and I lost it. Not because of the competition. Because I never figured out that the real decision maker wasn’t the VP of Engineering — it was the CFO who sat in on only one meeting and never spoke. That loss cost me six months of work. Cliento was born from that loss.

The Problem I Kept Seeing

After 30+ years closing complex B2B deals in industrial automation, robotics, and enterprise software, I kept watching the same thing happen:

Talented sales reps losing deals they should have won.

Not because of lack of effort. But because at 9pm before a critical meeting, there was no senior advisor to call. No one to help diagnose why a deal went cold. No framework to figure out who the real decision maker was.

So I built Cliento — an AI Sales Advisor that puts 30 years of real deal experience into the hands of every B2B sales rep.

What Cliento Does

Cliento is a conversational AI coach for B2B account executives navigating complex, multi-stakeholder deals.

Ask it anything about a live deal:

• “How do I find my real target customers?”
• “Who is the internal champion in this account?”
• “Why did this deal suddenly go cold?”
• “How do I prepare for a meeting with the CFO?”

Every response follows a structured format:

• Core Issue — what’s really going on
• Sharp Questions — what you need to ask yourself
• Direction — what to do next

The Tech Stack

Total infrastructure cost: near zero.
Deployment time: under 5 minutes.

Why DeepSeek?

I chose DeepSeek for three reasons:

1. Cost — fraction of GPT-4 pricing for similar output
2. Speed — fast response times for conversational use
3. Reasoning quality — surprisingly strong at structured sales reasoning when given the right prompts

The secret isn’t the model. It’s the prompt engineering built on 30 years of real sales frameworks.

The Architecture

export default async function handler(req, res) {
  const response = await fetch(
    'https://api.deepseek.com/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.DEEPSEEK_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: 'deepseek-chat',
      messages: req.body.messages
    })
  });
  const data = await response.json();
  res.json(data);
}

Simple. Secure. No API key exposed to the client.

The 10 Questions Cliento Answers

These are the real questions that win or lose B2B deals:

1. How do I find my target customers?
2. How do I uncover real pain points?
3. What background questions confirm a real opportunity?
4. How do I ask diagnostic questions?
5. Who is the internal champion?
6. How do I prepare for the key decision maker?
7. What’s my logic for saying this deal is 75% likely to close?
8. How do I handle last-minute negotiation obstacles?
9. How do I reach a win-win agreement?
10. How do I debrief what I won and lost?

What I Learned

Building this taught me something unexpec
ted: the hardest part wasn’t the code. It was distilling 30 years of sales intuition into structured prompts.

Every framework, every diagnostic question, every coaching sequence had to be precise enough that an AI could deliver it consistently — and honest enough that a senior sales leader would recognize it as real.

Try It

Live: https://cliento-sales-advisor.vercel.app

GitHub: https://github.com/andybai2000/Cliento-sales-advisor

It’s free. Open source. Deploy your own in 5 minutes.

Happy to answer questions about the sales methodology, the prompts, or the tech. Ask me anything below. 👇

A note for B2B sales teams in Asia: the decision chain in Chinese enterprise accounts is often invisible on the org chart. Cliento helps you map it.

Every SaaS billing integration starts the same way: you pick a provider, pull in their package, wire it up — and three months later when the business wants to add a second gateway (or swap to a Malaysian one like BayarCash or ToyyibPay because Stripe doesn’t do local rails), you discover your entire subscription layer is welded to the first provider’s package. Different webhook shapes, different status vocabularies, different model assumptions. You’re not adding a gateway; you’re re-architecting.

I kept watching this happen — especially in the Malaysian market, where the “obvious” global packages assume a gateway that half my clients can’t actually use. So I built cleaniquecoders/laravel-billing around one inversion: the gateway is the plugin, not the package. The engine owns subscription and invoice state. A gateway is a single contract your app implements. This post is less about the API surface and more about why it’s shaped this way — because the shape is the whole point.

The core decision: one package, gateways as a contract

The temptation when building a billing library is to ship laravel-billing-stripe, laravel-billing-bayarcash, laravel-billing-toyyibpay, and so on. It feels modular. It’s actually a maintenance trap — every gateway sub-package re-implements the same subscription lifecycle slightly differently, and the core can never assume a stable shape because each adapter bends it.

This package goes the other way. There is one package, one repo, and it never references a real provider by name. Instead there’s a single extension point:

namespace CleaniqueCodersLaravelBillingContracts;

interface PaymentGateway
{
    public function createCheckout(
        Billable $billable,
        Plan $plan,
        PlanInterval $interval,
        string $returnUrl,
    ): CheckoutIntent;

    public function cancel(Subscription $subscription): void;

    public function parseWebhook(Request $request): ?WebhookEvent;
}

Three methods. That’s the entire surface your app implements to onboard BayarCash, ToyyibPay, Chip, senangPay, Stripe, or anything else. The trick that makes it hold together is the two DTOs at the boundary — CheckoutIntent going out, WebhookEvent coming back:

final class CheckoutIntent
{
    public function __construct(
        public string $redirectUrl,   // where to send the customer
        public string $externalId,    // echoed back by the webhook for correlation
    ) {}
}

The gateway’s job is to translate the provider’s idiosyncratic world into these two neutral shapes. Once it does, the engine — subscription transitions, invoice issuance, events — never needs to know which provider it’s talking to. The provider-specific mess is quarantined inside one class instead of leaking through your whole billing layer. That’s the package-worthy lesson here, independent of billing: when you integrate N external services that do conceptually-the-same thing, define your own DTO at the boundary and make each adapter responsible for the translation. Don’t let provider shapes propagate inward.

Batteries included: a gateway that needs no merchant account

Here’s the part I’m most pleased with. A fresh install defaults to BILLING_GATEWAY=local, and the bundled LocalGateway runs the entire subscribe → activate → invoice → receipt flow with no real money and no merchant account. You composer require, run migrations, and the billing flow works immediately — in demo, in development, in UAT, in CI.

But it’s not a stub. This is the detail that matters:

// LocalGateway::createCheckout — approval flows through the SAME
// WebhookEvent path a real gateway uses
return new WebhookEvent(
    type: WebhookEventType::SubscriptionActivated,
    externalId: $payload['external_id'],
    amountCents: $payload['amount_cents'] ?? null,
    providerEventId: 'local-'.$payload['external_id'],
    rawPayload: $payload,
);

When you click “Approve” on the local dev checkout page, it produces a WebhookEvent and runs it through Billing::handle() — the exact same code path a real BayarCash webhook would take. It even HMAC-signs its checkout token with your app.key and verifies the signature on the way back, so signature-verification logic is exercised too:

public static function verify(string $token): ?array
{
    [$data, $signature] = explode('.', $token, 2);
    $expected = hash_hmac('sha256', $data, static::key());

    if (! hash_equals($expected, $signature)) {
        return null; // tampered or invalid
    }
    // ...
}

Why go to this trouble for a “dev” gateway? Because a fake that takes a different path than production is worse than no fake — it gives you false confidence. By making the local gateway flow through the real activation pipeline, your tests against local actually validate the pipeline a paying customer will hit. Set BILLING_LOCAL_AUTO=true and the whole thing runs synchronously in a single request, which is perfect for CI and feature tests. The local routes also refuse to register in production, so there’s no footgun.

Headless core, optional UI

The engine — models, services, contract, events, the manager — works with no UI at all. If you want billing pages fast, there’s an opt-in Livewire + Flux UI (plan picker, billing portal, receipt card) that closes the full loop. The guard is clean:

if (config('billing.routes.enabled') && class_exists(Livewire::class)) {
    // register /billing routes
}

If Livewire isn’t installed, or you set BILLING_UI_ENABLED=false, the package stays fully headless and you build your own pages against the same models and facade. No hard dependency on the UI stack bleeds into the core. This is the right default for a library: the opinionated convenience layer is there if you want it, but it’s behind a class_exists check and a config flag, never mandatory.

The webhook flow, and a replay guard worth stealing

Your app owns the route; the package does the work:

Route::post('/webhooks/{gateway}', function (Request $request, string $gateway) {
    $event = Billing::gateway($gateway)->parseWebhook($request);
    abort_if($event === null, 401);

    Billing::handle($event); // dedups, transitions state, issues invoices, fires events
    return response()->noContent();
});

parseWebhook() (your gateway’s code) verifies the signature and normalises the payload, or returns null to reject it. Then Billing::handle() delegates to a WebhookProcessor that replay-guards, locates the subscription, transitions status, issues an invoice on activate/renew, and fires the matching domain event.

The replay guard is a small thing I like:

protected function isReplay(WebhookEvent $event): bool
{
    if ($event->providerEventId === null) {
        return false;
    }

    $key = 'billing:webhook:'.$event->providerEventId;
    $ttl = (int) config('billing.webhook.replay_ttl', 60 * 60 * 24 * 30);

    // Cache::add returns false when the key already exists → replay.
    return Cache::add($key, true, $ttl) === false;
}

Gateways retry. They send the same event twice, three times, because they didn’t get your 200 fast enough. If you don’t dedup, you double-issue invoices. The neat part is leaning on Cache::add‘s atomicity — it only writes if the key is absent and tells you whether it won the race, in one operation. No read-then-write window for a concurrent duplicate to slip through. That’s a reusable pattern for any idempotent-event handling, not just billing.

State transitions live in one place

WebhookProcessor is where provider events become subscription state, and it reads like a state machine:

match ($event->type) {
    WebhookEventType::SubscriptionActivated => $this->activate($subscription),
    WebhookEventType::SubscriptionRenewed   => $this->renew($subscription),
    WebhookEventType::PaymentSucceeded      => $this->paymentSucceeded($subscription, $event),
    WebhookEventType::PaymentFailed         => $this->paymentFailed($subscription, $event),
    WebhookEventType::SubscriptionCanceled  => $this->cancel($subscription),
};

The gateway’s only responsibility is mapping its provider’s vocabulary onto these five WebhookEventType cases. Everything downstream — what “activate” means for period dates, when an invoice gets issued, which event fires — is decided once, in the engine, regardless of provider. A SubscriptionStatus enum carries its own access logic so the rule isn’t scattered:

public function grantsAccess(): bool
{
    return match ($this) {
        self::Trialing, self::Active, self::PastDue => true,
        self::Canceled, self::Incomplete => false,
    };
}

Note PastDue still grants access — a failed renewal shouldn’t instantly lock someone out mid-period. That’s a deliberate dunning-friendly choice, and because it lives on the enum, it’s consistent everywhere access is checked.

Polymorphic billing: tenancy is optional

The bill target is polymorphic, so the same engine serves single-tenant (User) and multi-tenant (Team/Workspace/Organization) without caring which:

class User extends Authenticatable implements Billable
{
    use HasSubscriptions;
}

HasSubscriptions satisfies the whole Billable contract and gives you the accessors the engine and UI depend on — subscription(), subscribedTo('pro'), onTrial(), onGracePeriod(), plan(), invoices(), plus metered-usage gating via canConsume('seats', 1) / recordUsage('seats', 1). To scope billing to a team instead of the logged-in user, you point one config closure at it:

'billable_resolver' => fn ($request) => $request->user()->currentTeam,

Every UI query and every invoice download is constrained to the resolved billable, and the download routes 403 on a foreign invoice — so one tenant can never see another’s invoices. Tenancy didn’t require a tenancy feature; it fell out of making the target polymorphic and routing all access through one resolver.

A few more details worth noting

Snapshot vs live. A subscription stores plan_tier as a snapshot string, but the live Plan is resolved from the repository at read time. So plan definitions can live in config or a database table (same PlanRepository interface either way), and a subscriber’s tier reference survives even if you restructure your plan models.

Atomic invoice numbers. Sequential numbering (INV-2026-000001) is allocated in a row-locked transaction, so concurrent issuance never collides on a number:

$sequence = $sequenceModel::query()->where('year', $year)->lockForUpdate()->first();
$current = (int) $sequence->next_number;
$sequence->next_number = $current + 1;
$sequence->save();

Malaysia-friendly, neutrally. MYR default, an SST/SSM-aware tax-invoice template, configurable seller details — but all neutral by default, so it’s not only a Malaysian package. The tax math is just round(subtotal * rate), stored as a breakdown on the invoice so the PDF renders correctly.

Events as your extension seam. The engine only updates state and issues invoices. Provisioning access, dunning emails, Slack pings — those are your listeners on SubscriptionActivated, SubscriptionRenewed, SubscriptionCanceled, PaymentSucceeded, PaymentFailed, InvoiceIssued. The package doesn’t presume to know your side effects.

When you’d reach for this

It fits when you want subscription + invoicing in Laravel and:

• you need more than one gateway, or a Malaysian gateway, or the freedom to swap later without re-architecting;
• you want the full flow working on day one — demo, UAT, CI — before any merchant account exists;
• you want a headless engine you can drive from your own UI, with an optional bundled UI when you’re moving fast;
• you bill teams or workspaces, not just users;
• you’re in a SST/SSM context and want sane local invoicing without a provider lock-in.

If you’re all-in on a single global gateway forever and its first-party Laravel package covers you, use that. The value here shows up the moment “which gateway” becomes a question with more than one answer — which, for anyone building for the Malaysian market, it always is.

It’s MIT-licensed and on Packagist:

composer require cleaniquecoders/laravel-billing

Repo and full docs (architecture, gateways, the full billing cycle, writing your own driver): github.com/cleaniquecoders/laravel-billing.

Implementing a gateway is one class and three methods — if you write a BayarCash or ToyyibPay driver, I’d love to see it.

Articles

🔍 Bucket4j + Infinispan: A Deep Dive Into Implementation

A code-level walkthrough of running Bucket4j rate limiting on top of embedded Infinispan. It traces how InfinispanProxyManager wraps a Bucket4j RemoteCommand into a SerializableFunction that runs as an AbstractBinaryTransaction on the primary node, deserializing RemoteBucketState, applying tryConsume, and writing the result back with a MetaLifespan TTL under atomic CAS evaluation. It rounds out with the protostream context initializer and the bytecode/version-homogeneity constraints you need to get it working.

🔍 Building a High-Performance API Gateway with Vert.x: Architecture Deep Dive

A production look at building an API gateway on Vert.x and the performance contract that comes with it. The Router handler pipeline chains stages through routingContext.next(), short-circuiting on auth or validation failure, while blockingHandler keeps slow work off the event loop. The piece treats handler ordering as a security property and digs into worker-pool exhaustion tuning and the fail-open vs fail-closed call when a downstream key/auth service times out, all grounded in real profiling.

🔍 Deploying a Multi-Cloud API Gateway from Scratch: Architecture, Failure Modes, and Hard-Won Lessons

Building a multi-cloud API gateway from the ground up, with the failure modes spelled out. A Go control plane watches versioned JSON route configs in Redis and serves them to Envoy over xDS, shifting traffic weights when backend error rates cross a threshold. The hard-won lessons are the good part: rate limiting silently fails open when the gRPC limiter is unreachable, a Redis restart can hand Envoy empty clusters (fixed with in-memory plus disk read-through), and OTLP exporters drop spans without retry_on_failure and a sending queue.

🔍 Deploying MCP servers in production: the 2026 attack surface and the defense stack

A practical MCP threat model that maps the disclosed 2026 CVE classes onto a six-layer defense stack and a seven-question go/no-go checklist. It walks the mitigations layer by layer: pin and mirror servers against supply-chain attacks, harden the schema contract, validate OAuth 2.1 PKCE tokens via RFC 7662 introspection with agent-scoped delegation (RFC 8693), inspect tool descriptions, args, and responses at the gateway to catch prompt injection and rug-pulls, log every call, and isolate at the OS level (containers, gVisor, Firecracker) rather than trusting JS sandboxes.

🔍 Designing the outbound delivery log: what to store, what to expose, what to keep

A field guide to designing a durable outbound delivery-attempt log: what to store, what to expose, and what to throw away. It proposes a four-part field taxonomy (identity, lifecycle, outcome, observability) anchored by status, error_category, and latency_ms, then splits the hot write path from a warm/cold query path on an OLAP store. Customer-facing views are workspace-scoped with header/body sanitization and translated errors, and retention is tiered: full samples hot, metadata-only warm, outcome-only cold, with explicit delete-or-aggregate handling for PII.

🔍 Enterprise-grade Authorization for MCP Servers

An end-to-end “OAuth for MCP” authorization design. It maps the MCP client/server/resource-server roles, wires up discovery via RFC 9728/8414 and dynamic client registration (RFC 7591), then mandates PKCE with S256 challenges for loopback redirects. Access tokens stay short-lived and scoped (minutes), refresh tokens rotate with replay detection and immediate revocation. The author is candid about OAuth’s limit: a valid token still can’t stop payload-driven prompt injection.

🔍 Event Replay Will Take Down Production. Here’s How to Tag Replay-Safe vs Replay-Toxic Events at the Schema Level.

A schema-first way to stop event replay from taking down production. Events are tagged replay-safe, replay-restricted, or replay-toxic via an x-replay-policy field carried in Avro, Protobuf, and JSON Schema. The runtime replay gate fails closed on missing or unknown policies, propagates a replayMode flag to suppress external side effects for restricted events, and routes toxic events to forward-only reconciliation with compensating actions. A nightly drift detector rebuilds projections in a sandbox to catch misclassification before a real replay does.

🔍 Event Schema Evolution: 4 Versioning Strategies, 1 That Quietly Breaks Consumers

Four schema-versioning strategies compared over a year-one-to-year-five horizon, and the one that quietly breaks consumers. The silent failure: versioned topics where producers retire v1 before every consumer has migrated. The fixes are concrete: a consumer-topic gap monitor, an expand-contract flow that gates contraction on a schema_version_consumed readiness check plus registry cross-checks, and an upcaster pattern that versions the read path with chained transformers (with notes on error compounding and caching cost).

🔍 Event-Driven vs Polling Architectures

A clear-eyed comparison of how agent systems get their triggers: webhooks, log-based CDC, message-bus subscriptions, and plain polling, each mapped to its delivery contract and failure modes. It covers provider-specific retry/order/rate-limit quirks, explains CDC as WAL replay with per-partition ordering and WAL-accumulation risk, and shows why agent runtimes need durable state across waits. The recommendation: webhook-plus-reconciliation, with a structural idempotency key (agent_run_id, step_id, tool_name, call_index) at the write boundary to make at-least-once delivery safe.

🔍 How Agoda Simulates Booking Flows to Test Flight Integrations

How Agoda replaced brittle connector end-to-end tests with a supplier-agnostic Workflow Simulator for flight bookings. A Scenario Builder generates deterministic or randomized context, a Workflow Executor models the booking as a DAG, and shared state is carried across calls as nodes are traversed. Endpoint assertions check contract and schema constraints while workflow assertions verify cross-step data propagation against recorded request-response pairs, with an honest note on where it still can’t model race and rate-limit effects.

🔍 How LI.FI Added Enterprise Auth to Apache Superset’s MCP Server

A start-to-finish account of putting enterprise auth in front of Apache Superset 6.1’s MCP server with Okta OIDC. It extends FastMCP’s OIDCProxy to call Okta /userinfo during the token exchange, folds the upstream email into the FastMCP JWT, and monkey-patches get_user_from_request to set g.user from that claim. For Okta org-AS opaque tokens it swaps JWKS validation for an IntrospectionTokenVerifier via RFC 7662 /introspect, fixing the 401 invalid_token, and closes with RBAC setup and Helm/K8s deployment gotchas.

🔍 How we built integration testing for fast-moving AI backend

A full integration-testing setup for a backend whose AI dependency moves fast. It boots a real Llama Stack as a uv subprocess with health-check seeding, injects an X-LlamaStack-Provider-Data test id through a custom Go transport, and runs CI in two phases: replay first, then record to refresh fixtures only on mismatch. A scheduled “Compatibility Sentinel” GitHub Action resolves stable and dev releases, reruns the suite against pinned Makefile versions, and posts structured Slack status so contract drift surfaces weeks ahead.

🔍 Notion’s 2026-04-01 API changed pagination cursors and the RateLimit-Reset format — here’s what silently breaks

A close read of two Notion changes that keep the same shape but change meaning, and the integration bugs they cause. Persisted pagination cursors and rate-limit backoff are the casualties: store the Notion-Version next to each cursor and reject cross-version replay (old UUID cursors still work, new base64 ones break on older versions), and read x-ratelimit-reset as a seconds duration with sane min/max bounds and alerts on negative or absurd waits. It ends with a migration test you can run against live 429s and paginated queries.

🔍 OpenAPI 3.1 in Practice: What I Learned Publishing a Real-World Swap API

A hands-on playbook for shipping a real OpenAPI 3.1 spec. It leans on JSON Schema 2020-12-native constructs (type [.., null], examples[]), models webhooks and events directly in the 3.1 document, and publishes from a dedicated git-tagged repo that regenerates /openapi.json on deploy. The client strategy is two-tier: hand-written canonical Python/TS SDKs alongside generated “second-tier” clients, with live API tests to catch spec/implementation drift and semver-mapped URL versioning (/api/v2 vs /api/v3).

🔍 Saga Compensation When Undo Is Impossible: 3 Patterns and the Audit Trail

What to do when a saga’s compensation step can itself fail. The author pairs three patterns (forward recovery, the authorize/commit pivot, and a reconciliation queue) with a concrete append-only audit trail. It shows how to mark step deviations with explicit Outcome states, implement payment pivots with idempotency and expiry-aware timeouts, and park ambiguous stuck entries with the operator actions available to resolve them, explaining why causation_id, actor, and external_refs are non-negotiable for end-to-end traceability.

🔍 What’s old is new: A NATS-native protocol for AI agents

A pinned, NATS-native interoperability contract for AI agents. Discovery runs over $SRV.PING.agents/$SRV.INFO.agents; a conversation is a single request whose reply streams typed JSON {type,data} chunks, starting with a mandatory status=ack and ending with a zero-byte terminator; liveness rides fixed agents.hb.{agent}.{owner}.{name} heartbeats plus agents.status.* subjects. The spec also nails down envelope discrimination (UTF-8 text vs JSON), queue grouping, capability metadata, and error-header semantics.

🔍 Your Integration Logs Say Everything Is Fine. Your Best Customer Can’t Check Out.

A production post-mortem on “silent” semantic drift: ghost addresses appearing between Business Central and Adobe Commerce while the integration reported zero errors. The root cause was missing update intent. The fix translates ERP record identifiers into explicit eCommerce commands: a matched ID becomes an update, an unmatched one an insert. Bulk re-sync is rearchitected to update-and-verify only, killing the duplication and cutting checkout latency.

🔍 Your Shopify discount is in the admin but missing from the API — the 2026-07 market-eligibility trap

A version-gated data-integrity trap in Shopify’s discount APIs. On Admin API versions before 2026-07, market-scoped discounts vanish from discountNodes and return null when fetched by ID, so reads look like deletions and quietly corrupt reconciliation and bulkOperationRunQuery results. The remedy: upgrade to 2026-07, count the version diff, and map discounts with market-type and inheritance awareness using the market_ids context.

🔍 How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns for Distributed Architectures

A bounded-reliability playbook for API-led stacks (Gateway, Experience, Process, System, ERP) showing how well-meaning fault tolerance correlates into cascading failure. It dissects three traps: retry storms, where independent per-layer retries multiply load; synchronous replication fan-out collapse; and autoscaling that feeds on retry-inflated metrics. The remedies are equally concrete: capped, jittered exponential backoff with a load-aware short-circuit; tiered durability scoped by criticality; and autoscaling on organic RPS rather than retry-driven spikes.

Apache Camel

🔍 Apache Camel AI: Building an Email Triage Agent with OpenAI, Gmail Transformers, and Camel JBang

An end-to-end Camel pipeline that orchestrates an LLM in YAML and JS. It sanitizes raw Gmail HTML with a custom SimpleFunction chained through Camel 4.18’s ~> operator, then calls camel-openai chat completion with a jsonSchema to force a constrained category/needsReply response. A Choice routes to direct:handle-triaged-email, wireTap handles async reply drafting, and 4.19 DataType Transformers (google-mail:update-message-labels, google-mail:draft) build the ModifyMessageRequest and Draft objects without hand-written API models.

Apache Kafka

🔍 Architecting Cloud-Native Kafka

Turns Kafka’s cloud-native features into concrete FinOps and platform-governance workflows. It covers KIP-405 tiered storage and when object-storage reads actually pay off, then uses KIP-1267-style RemoteFetchBytesPerSec and RemoteFetchRequestsPerSec JMX telemetry to drive Prometheus/Grafana chargeback and quota throttling. It also weighs KIP-848 incremental rebalance for safe HPA/KEDA scaling, KIP-932 share-group tradeoffs, and KIP-1150 diskless-migration risks like orphan segments and EOS/LSO uncertainty.

🔍 Benchmarking the Kroxylicious Proxy

A reproducible benchmark for sizing the Kroxylicious proxy. It compares a Kafka baseline, Kroxylicious passthrough, and AES-256-GCM record encryption (Vault KMS) using OpenMessaging Benchmark rate sweeps on a fixed OpenShift/Kafka testbed. Passthrough overhead is negligible; encryption costs roughly 25% throughput and saturates earlier. From the data the author derives a CPU planning formula, CPU(mc)=k×(P+N×C), with measured k coefficients and a requests=limits pod-spec rule that makes the proxy’s throughput ceiling predictable.

🔍 Designing a High-Throughput Webhook Delivery System at Scale

An implementation-grade design for high-throughput webhook delivery. It uses a per-entity-type transactional outbox (partitioned by tenant), a DB-based distributed mutex with heartbeats to coordinate pollers, and Kafka topics per entity type keyed by entity_id for strict per-entity ordering. Delivery runs on Java 21 virtual threads with per-customer semaphore concurrency and endpoint circuit breakers, and the DLQ deliberately avoids auto-replay, offering explicit resume and rate-limited controlled replays from the current offset instead.

🔍 Kafka’s Real Compression Problem Is Batch Depth

A causal model for why Kafka compression underperforms: shallow producer batches give the codec less redundancy to work with, which shrinks compressed batches and piles fetch overhead onto consumers across fan-out. The author localizes the fault with batch-fill-rate, producer-compression-rate, and consumer-fetch-size metrics, then fixes it in order: raise linger.ms, grow batch.size within buffer.memory, switch to zstd level 1 for structured data, and align fetch.min.bytes/fetch.max.wait.ms to the new batch shape.

🔍 Messaging in the Age of AI

A concrete Kafka-plus-Spring blueprint for agent messaging under nondeterminism. Messages carry an envelope with tokenCount, trace lineage, senderType, modelId, and an agent idempotencyKey, and traffic is split into lane topics with their own retention. The consumer side does chunked context assembly, enforces token-aware per-lane quotas with backpressure for cost control, and layers in lineage-focused JSON observability plus messaging-bound safety filtering.

🔍 Ursa — a new Diskless Lakestream engine for Kafka

Ursa is a Kafka storage extension that decouples durable log data from strongly consistent metadata (via Oxia), enabling diskless topics with native Iceberg/Delta visibility. Brokers buffer writes (4MB/200ms), sort by topic-partition id, and flush mixed-partition objects to S3 with null offset metadata, then atomically update per-partition offset and data pointers in Oxia. A compaction manager rewrites that mixed data into columnar Parquet and commits batched files to the Iceberg/Delta catalog, making the streams queryable as lake tables.

🔍 We Proved Multi-Cluster Kafka Works on Kubernetes… Here’s Everything we Learned

An end-to-end stretch-cluster prototype that keeps Kafka running through a full Kubernetes cluster failure. A central Strimzi operator manages the Kafka CRs while remote clusters run constrained reconciliation, and the trick is in the networking: modified Strimzi deterministic .clusterset.local DNS (via stretch-cluster-alias annotations) plus extended TLS certificate SANs make advertised.listeners and controller.quorum.voters work across 2–10ms links. The writeup includes measured quorum, leader-election, and failover behavior.

🔍 Why 80% of Kafka Clusters Would Fail a SOC 2 Audit Tomorrow

Evidence from 50 production-cluster scans on why most Kafka deployments would flunk a SOC 2 Type II audit. It maps specific misconfigurations to concrete control statements (CC6.7 inter-broker PLAINTEXT, CC6.1 wildcard ACLs and missing auth, CC8.1 topic auto-creation) and prescribes the fixes: SSL-only inter-broker protocol, SASL_SSL listeners, disabling auto.create.topics.enable, authenticated and segmented JMX, and an audit-log authorizer with proper retention windows.

Azure

🔍 MCP Meets Entra ID: Solving the Dynamic Client Registration Problem

A transparent OAuthShim that retrofits RFC 7591 dynamic client registration onto Entra ID, which lacks a /connect/register endpoint. Sitting in front of Claude Code, the shim handles discovery via APIM-injected WWW-Authenticate and a mock /.well-known/oauth-protected-resource, issues ephemeral client_ids, proxies the authorization code plus PKCE to Entra, and returns unmodified JWTs for APIM’s validate-azure-ad-token. It includes the APIM inbound policy chain, Redis-backed shared state for multi-instance redirects, and operational hardening (HTTPS, logging, rate limits).

MuleSoft

🔍 How I Built an Event-Driven Integration Platform for Healthcare Using MuleSoft

A full enterprise blueprint that pairs MuleSoft’s API-led layers (System/Process/Experience) with a custom async bus (LEXI) for healthcare product-data updates. It enforces a canonical model through DataWeave mappings, standardizes event contracts (eventId, correlationId, delta changedFields, SemVer), and implements subscriber idempotency with MANUAL ack on Anypoint MQ. Errors are classified for retry vs DLQ replay, and the design wires correlation-id observability alongside active-passive multi-region DR (RTO<15m, RPO<5m).

🔍 Stop using to aggregate arrays — here’s why it silently destroys performance in Mule 4

A Mule 4 performance pitfall worth knowing: accumulating results with triggers O(N²) array copies because DataWeave payloads are immutable. The pragmatic fix is to use (optionally capped with maxConcurrency) to return a MessageCollection, then run a single DataWeave transform to extract payloads, dropping the copy work to O(N), with the composite-error handling that approach requires.

Redis

🔍 Idempotent Consumers: Dedup Key, Dedup Window, or Idempotency by Design. Pick One

A failure-mode-driven “pick one” matrix for idempotent consumers, with implementation guidance for each. Use SETNX dedup keys with a TTL tuned to worst-case redelivery; reach for LRU+Bloom only when restart/eviction gaps cause bursty duplicates; and prefer idempotency-by-design via atomic state-transition SQL (WHERE pending) with side effects guarded by external idempotency keys. It also sketches a layered retrofit (window, then storage, then a design backstop) to survive Redis failover and process restarts.

SAP

🔍 Under the Hood: How SAP Integration Suite Really Works

A look under the hood of SAP Integration Suite. It follows an iFlow from BPMN-like XML versioned in the TMN control plane, through compilation into Camel DSL, packaging as an OSGi bundle, distribution, and hot activation in Karaf without a JVM restart. Along the way it explains the five-stage deploy pipeline and why activation takes 20–40s, then traces a message through the Camel Exchange (headers/body/properties) and the generated Processor chain, with SAP adapters as the protocol entry and exit points.

WSO2

🔍 Governing AI Agent Access to MCP Tools with WSO2 AI Gateway and WSO2 Identity Server 7.3.0

A concrete WSO2 reference architecture for governing MCP tool calls with a gateway and first-class agent identities. WSO2 IS 7.3.0 registers agents and mints signed JWTs carrying aut=AGENT and sub=AgentID, and the WSO2 AI Gateway enforces two policies: mcp-auth for JWKS-backed JWT validation and mcp-acl-list for allow-mode access with per-tool exceptions. An mcp-authz policy then maps MCP tool names to IS scopes for per-agent RBAC, demonstrated with end-to-end curl tests showing 401 and MCP capability errors.

Releases

🚀 Apache Kafka 4.3.0

Kafka 4.3.0 lands a broad set of broker and platform knobs across 25 KIPs. Highlights include tiered-storage follower bootstrap (follower.fetch.last.tiered.offset.enable), operational cordoning via cordoned.log.dirs, and controller fetch/snapshot limits (controller.quorum.fetch.max.bytes and .fetch.snapshot.max.bytes). On the client side it adds OAuth client-assertion support for client_credentials, refines group assignment and epoch handling, and expands state and storage metrics; Streams and Connect gain state-store header support and ConnectPlugin unification.

🚀 Arazzo Specification 1.1

Arazzo 1.1.0 extends declarative workflow specs beyond OpenAPI by adding AsyncAPI-backed steps: sourceDescriptions can now reference asyncapi with send/receive actions, dependsOn, correlationId, and successCriteria, plus chained workflows with fixed parameters. It also introduces a Selector Object (jsonpath/xpath/jsonpointer with version pinning), formalizes source resolution and a runtime-expression ABNF, adds identity-based $self URIs for unambiguous cross-document resolution, and aligns querystring parameter handling with OAS 3.2.

🚀 Kroxylicious 0.21.0

The headline of Kroxylicious 0.21.0 is deep integration plumbing. A Kubernetes admission webhook injects a proxy sidecar from a KroxyliciousSidecarConfig, virtual clusters gain graceful draining via drainTimeout with completion/timeout metrics, and the proxy now handles the HAProxy PROXY protocol ahead of TLS. On the security and data path it adds Strimzi CA trust discovery, AWS KMS IRSA/EKS Pod Identity credential providers, a ServerTlsCredentialSupplier for dynamic upstream mTLS, and Avro/Protobuf record validation against Apicurio Registry.